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(57) Abstract 



A file transfer device, system, and method are provided. 
The device, system, and method enable a variable number of data 
transfers and include an initial connection system and a data transfer 
^ system. The initial connection system establishes a connection 
between at least two devices via predetermined listening ports, 
with at least one predetermined listening port residing within each 
of the at least two devices. The initial connection system also 
dynamically assigns a first data port within a first device, and 
transmits the address of the first data port to a remaining device 
via the predetermined listening ports. The data transfer system is 
for each of the variable number of data transfer operations. The 
data transfer system dynamically assigns a corresponding second 
data port within die remaining device arid transfers data between the 
connected devices via the data ports so that the data is substantially 
simultaneously transferred between a variable number of devices via 
the data ports. Each pair of first and second data ports is established 
in response to each listening port connection. 
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FILE TRANSFER SYSTEM 
CROSS REFEREiNCES TO RELATED APPLICATIOiNS 
This application claims the benefit of U.S. Provisional Patent Application No. 
60/065,533, in the names of Maurice Haff ei. al., entitled 'Tile TransferSystem For 
Direct Transfer Between Computers" (Attorney Docket No. V16089), filed on 
November 13, 1997; U.S. Provisional Patent Application No. 60/085,427, in the 
names of Maurice Haff et. ai., entitled "File Transfer System" (Attorney Docket No. 
V16057), filed on May 14, 1998; and U.S. Provisional Application No. 60/100,962, 
filed September 17, 1998; the disclosures of which are expressly incorporated herein 
by reference in their entireties. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to transferring computer files electronically from 
one location to another, and more particularly to electronic transfer of computer files 
directly between two or more computers or computing devices. 

2. Background of the Invention and Related Art 

Expedited delivery of documents has for generations been of great concern to 
people and of great importance to their business interests. Methods of effecting 
expedited document delivery have progressed to include same day/next day physical 
delivery using international and domestic airways and roadways, as well as electronic 
delivery using interconnected networks of computers and telecommunications 
equipment, worldwide. Complex logistics systems have been erected by both 
government and commercial enterprises to effect relatively secure physical delivery 
of documents from the sender to the recipient. Examples include overnight express 
mail delivery offered by the U.S. Postal Service and express delivery service provided 
by private companies such as Federal Express, United Parcel Service, and DHL. 
Charges for delivery services rendered are typically on fixed fee basis (per delivery), 
with payment made at the time the service is performed, or made via a pre arranged 
account with the service provider or a third party credit provider (e.g. VISA or Master 
Card). 

SUBSTITUTE SHEET (RULE 26) 
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The complexity of these systems and the physical resources mobilized to 
support the expedited transfer service are relatively costly, w^ith the costs being 
passed on to the service user. Extensive interconnected networks of computers and 
telecommunications equipment have been erected with the intent to lower the cost of 

5 communication, as well as to further expedite the transfer of information between 
sender and recipient. To an extent, the evolution from physical deUvery to electronic 
delivery of documents has been successful as evidenced by the grow^ in the use of 
personal computers (PCs), the Internet and private intranets and extranets, albeit at 
the e?q)ense of the relative security of the document transfer. Examples of electronic 

1 0 transfer mechanisms in use across computer networks include electronic mail (e-mail) 
and file transfer protocol (FTP), both widely employed on the Internet. Examples of 
electronic transfer mechanisms in use across the public switched telephone network 
(PSTN) include facsunile transmissions, as well as file transfers using modems and 
various embodiments of computer programs enabling data communications between 

15 computers. 

Hybrid systems are also employed to provide remote access to files stored on 
network servers. These hybrid systems typically employ specialized conmiiunications 
servers connected on a local area network and interconnected to a counterpart 
communications server on another local area network through a public network such 

20 as the Internet. Altematively, a remote PC may be permitted to login to a 
communications server using a dial-up connection through the PSTN. Often referred 
to as "virtual private networks" or VPNs, these hybrid systems typically employ 
encrypting techniques to create relatively secure data packets for transmission 
through client-server connections across public networks. An example of a VPN 

25 product is Alta Vista, a software product available from Digital Equipment 
Corporation. 

The approaches, as embodied in the physical and the electronic document 
delivery systems in use today, exhibit a number of shortcomings. While being 
relatively secure, slower express mail and delivery services are more costly to the 
30 sender than more immediate delivery electronic altematives. With electronic 
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transfers across networks, a more immediate delivery of documents, data files, 
images, and drawings can be accomplished. However, these methods generally 
employ intermediary computers in the form of e-mail servers, FTP servers, or Web 
servers. These intermediary computers reduce the relative security and timeliness 
5 of the transfers effected because neither the sender nor the recipient controls the 
intermediary server. Moreover, the intermediary servers themselves require 
significant administration and usually require login procedures and passwords in an 
attempt to overcome security issues, albeit at the expense of user convenience and 
system complexity. Further, these intermediary computers represent concentrated 

10 points of possible failure, as well as communication "bottlenecks" that set capacity 
limits for the collective number and size of files transferred. 

Examples of an approach employing e-mail servers are cc:Mail available fi-om 
Lotus Development Company, and Microsoft Mail available fi-om Microsoft 
Corporation. An example of a system employing FTP servers and Web servers for 

15 IP networks is Netscape Navigator available fi-om Netscape Conmiunications 
Corporation. Each of these systems requires intermediary computers that fimction as 
servers to store text messages or document files for later retrieval by the intended 
recipient. All of these systems require user login to a server and downloading of 
files. Thus, direct transfer of a specific file from a sending PC to a specific recipient 

20 at a receiving PC is not enabled by these systems, nor is the simultaneous exchange 
of files between multiple computers. 

A variation of the e-mail concept is manifested in a recently introduced file 
transfer service called "e-Parcel" available over the Internet from Mitsubishi 
America. "e-Parcel" is a pay subscription service employing client-server 

25 connections through the Intemet. A similar system called "NetDox" is available from 
NetDox, Inc. Both of these products employ client software to provide automatic 
login to a mediating server that forwards a transferred file to a registered recipient 
when the recipient logs in to the mediating server. E-mail addresses are used to 
create unique identifiers for each registered user for file routing and billing purposes. 

30 However, direct transfer of a file from tiie sender to the recipient without login to the 
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forwarding server is not possible in server-based mediated systems such as e-Parcel 
or NetDox. Another drawback of server-based systems is that they are capacity 
limited in terms of the number of file transmissions that can be processed 
simultaneously, and the magnitude of the files that can be collectively stored during 
5 any given time period. Server capacity must be increased proportionally, at 
significant cost, as the number of users and system use increases. Another limitation 
of store and forward (mediated transfer) servers is that concentration of transmitted 
files represents a system-level point of failure that increases both security and 
reliability risks. 

1 0 In any document delivery system, physical or electronic, a manageable method 

of obtaining payment for the services rendered to the user is a critical element for 
success. In physical delivery systems for expedited service, payments are often made 
for charges to a billing account accumulated monthly, with the account numbers 
being recorded on an "airbill" that accompanies the document package. A record of 

15 the transaction must be captured, usually by a manual process, and entered into a 
computer accounting system. The United States Postal Service (USPS), as well as 
other national postal systems, have long offered mechanical postage meters for 
placing "metered stamps" on envelopes to be sent through the mail. These 
mechanical postage meters must be taken by the user to a "post office" to be reset. 

20 This enables a postal service to capture payment for fiiture services to be delivered. 

A VEiriation of the traditional postal meter is a newer technology electronic 
postage meter offered by Pitney Bowes, Inc., called "PERSONAL POST OFFICE"®. 
The electronic postage meter can be reset over telephone lines with charges made to 
a Pittiey Bowes "POSTAGE BY PHONE"® account. Pitiiey Bowes also offers a 

25 "Post Office for the PC" product that enables "metered" post marks to be printed onto 
envelopes using a personal computer printer. A peripheral device attached to the 
personal computer serves as the postage repository, with postage downloaded via 
modem over telephone lines. 

Payment for the service provided by e-Parcel is via a prearranged flat rate 

30 monthly charge, with the charge being determined upon registration based upon 



wo 99/26121 PCT/US98/24373 

Page -5- 

projected use and transmission file size. An alternative payment plan, pay upon 
transfer service, has been advertised and charges a fee for each file sent through an 
e-Parcel server. Payment for the service provided by NetDox, Inc. is via NetDox 
server software licenses. 
5 United Parcel Service, Inc. (UPS) has announced a mediated electronic 

document file delivery service based upon the NetDox product, and also based on 
another store and forward server based product called "Posta", available from 
Tumbleweed Software, Inc. The UPS system is represented to be an electronic 
document delivery service for which the user establishes a billing account that will 

10 be charged for each document file sent through the UPS servers. 

Facsimile transmissions across the PSTN, compliant with CCIPP Group 3 
facsimile standards, are relatively direct, immediate, and secure fi-om third party 
interception. However, facsimile transmissions can pose a multitude of transmission 
management and processing problems for both, the sender and recipient. For 

15 facsimile transmissions, the "service providers" are the local and long distance 
telephone companies that charge for the connect time required to send a fax. 

Examples of devices using CCITT Group 3 facsimile transmission standards 
are widely deployed fax machines available from a multitude of manufacturers, such 
as Hewlett Packard Corporation and Panasonic Corporation. Additional examples 

20 of devices employing the Group 3 facsimile standard are the widely deployed PC fax 
modems available from manufacturers such as US Robotics Corporation. Both fax 
machines and fax modems communicate over the PSTN. An emerging technology 
is transmission of fax images over the Intemet. While fax devices enable direct 
transmission of a specific document image from a sender to a specific recipient, the 

25 transmissions are not in the original file format of the document transmitted and 
typically suffer degraded visual quality. PC fax transmissions resuh in very large file 
sizes drivmg requirements for large storage capacity. 

Unlike facsimile image transmissions, electronic file transfers across networks 
or through the PSTN using modems can render document files to the recipient in 

30 native format, whether text, graphics, drawings, video, or sound. Such files may 
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contain large format drawings or large page count documents. Unlike e-mail with 
attachment files, electronic file transfers generally do not suffer problems with 
unpredictable delivery, third party mail server security, nor attachment file encoding 
compatibility. However, mediated file transfer using client/server communication 

5 across wide area networks typically requires login to a network server, and can pose 
security risks when access is permitted for remote users or an organizationally 
unrelated third party. 

File transfers throu^ the PSTN using modems and the prior communication 
architectures with accompanying computer programs usually require user attendance 

10 to effect the transfer between PCs. Alternatively, remote control of one PC from 
another PC with attendant security risks is allowed. Thus, all of the mechanisms in 
the prior art for effecting electronic file transfer, whether across the Internet, private 
intranets or extranets, or through the PSTN, require a multitude of process steps and 
a significant degree of user training. 

1 5 An example of an approach designed to provide user access to document files 

across a network is described in U.S. Patent No. 5,634,057. This patent describes 
groupware, in which multiple users logged on to a network can interactively 
collaborate regarding various aspects of documents such as form and content. 
Typically, groupware suffers from its own complexity of use and does not enable 

20 direct transmission of a specific file from one PC to another PC, or a simultaneous 
exchange with multiple PCs. 

Another example of an approach accomplishing file transfers directly from a 
sending PC to a receiving PC through the PSTN, and in some instances through the 
Intemet, is a class of products described as "remoteware". Within this category, 

25 specific products such as "pcAnywhere", available from Symantec Corporation, 
enable a user to login from one computer to another computer and effectively take 
control of the operation and stored files of the computer onto which login was 
accomplished. However, direct transfer of files without the third party security risk 
of login and control is not provided. Additionally, products such as "DynaComm", 

30 available from FutureSofl Engineering, Inc., are designed to provide dial-up terminal 
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access to servers and mainframe computers across the PSTN. Such products are also 
typically capable of direct PC to PC transfer of files, provided a PC operator is 
available and ready at both the sending and receiving PC to setup the parameters and 
conditions under which the transfer will be made. 

5 Another example of an approach that enables transmission of a single file from 

one PC to another PC interconnected to a Transmission Control Protocol/Internet 
Protocol (TCP/IP) network is a demonstration computer program called "Wormhole", 
available over the Internet from Microsoft Corporation, The purpose of this freeware 
computer program is to demonstrate how a socket data structure functions under the 

10 Microsoft Windows operating system. This demonstration program is capable of 
sending only one file to only one PC at a manually entered IP address. No restrictions 
can be placed on when or where files can be transmitted, nor from whom they are 
received. Simultaneous exchange of files with more than one PC is not enabled nor 
suggested. Furthermore, no PSTN communication and no error checking or 

15 verification of the file transfer is provided. Moreover, no indication of where files 
originate from is provided. In addition, no communication or file controls are 
enabled. Also, it is not possible to request a file from a PC operating the Wormhole 
computer program, nor is any fomi of file transport security provided. 

Another example of an approach that enables direct PC to PC communication 

20 through the PSTN, developed by the current applicant, is the AEGIS Document 
Imaging System (ADIS). In ADIS, document management and communication 
fimctions are integrated to provide a system for creating a virtual PC network 
interconnected through the PSTN. In addition to imaging capable PC equipment, 
ADIS requires specific conmiunication hardware (e.g., SatisFAXtion 400 fax modem 

25 developed by Intel Corporation, available from Pure Data, Ltd., Ontario, Canada), 
and uses a file transfer mechanism built into the SatisFAXtion board controlled by 
the ADIS computer program. No capability for direct file transfer across the PSTN 
using widely deployed standard Hayes compatible data modems, or across a TCP/IP 
network, is included in ADIS. Moreover, file requests can be made from one ADIS 
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station by another ADIS station, but file requests can not be restricted to a specific 
station. 

Another drawback of these conventional systems is that polling of a remote 
computer, when such capability is present, occurs serially. Thus, a long time is 
5 required to receive many files firom many different destinations, particularly if one 
of the destinations is busy, causing the polling computer to repeatedly attempt to 
contact the destination before ultimately timing out. 

Another example of a known file transfer system is DropChute+, available 
fi-om Hilgraeve, Inc. of Monroe Michigan. Drop Chute+ utilizes a single port, thus 
10 limiting commxmication to one other computer at one time. DropChute+ cannot 
communicate simultaneously (transfer files in parallel) with one or more other 
computers. Moreover, with DropChute+ all transfers and commands take place on 
a single port. If more than one event is to occur, all events are multiplexed through 
the single port. Furthermore, if a user wants to send a file to a group of destinations, 
1 5 there is simply no way to do it under DropChute+. 

Thus, there is a need for a system to provide inmiediate and secure assured 
delivery of documents from sender to recipient which retains the positive aspects of 
the prior art, but does not suffer fi-om its shortcomings. 

SUMMARY OF THE im^ENTION 
20 In view of the foregoing, the present invention is directed to providing a 

communication system for effecting peer to peer electronic transfer of computer files 
between PCs across the Internet, private intranets and extranets, and the PSTN. 

File transfers are via the Intemet, private intranets or extranets, and the PSTN 
without login to the remote computer and without intermediate storage of the files on 
25 an intCTvening computer. The present invention enables simultaneous transfers and 
mcorporates fimctions including certified return receipt for transported files, transport 
initiation directly fi-om any companion application program, and mechanisms for 
effecting payment to a service provider for each transported file. 
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The present invention is further directed to providing a communication system 
that enables file transfers between PCs in native format without requiring encoding 
or conversion of the format of the files transmitted. 

The present invention is further directed to providing a communication system 

5 that enables file transfers between PCs without a . requirement for login to an 
intervening computer other than to establish a communications pathway. 

The present invention is further directed to providing a communication system 
that enables file transfers between PCs without the necessity for an operator to be 
present at either the sending or receiving PC. Thus, it enables file transfers between 

10 PCs at a scheduled time predetermined by the sender. 

According to an aspect of the invention, the invention is directed to a file 
transfer system for transferring files between a local computer and at least one 
destination computer selected fi'om a list of destination computers. The transfer is 
across at least one communications pathway, including a computer network and a 

15 public switched telephone network. The file transfer system includes a file selector 
that selects at least one file stored on the local computer for transferring to the at least 
one destination computer(s); a destination selector that selects, firom a list of the at 
least one remote computer(s), at least one destination computer to which the file will 
be transferred; a transmitter that transfers the selected file(s) to the destination 

20 computer(s) via the communications pathway without storing the selected file(s) on 
any intermediate computers; and a receiver that receives the transferred file(s). 

According to another aspect of the file transfer system of the present 
invention, the transmitter also includes a compressor that compresses files prior to 
transmission. The receiver also includes a decompressor that decompresses all 

25 compressed files upon receipt. Preferably the compressor compresses every file prior 
to transmission. Alternatively, the compressor only compresses user selected files. 

The transmitter also includes an encryptor that encrypts each file prior to 
transmission. The receiver also includes a decryptor that decrypts each file upon 
receipt. In such a file transfer system the encryptor encrypts every file prior to 

30 transmission. 
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In accordance with a preferred embodiment, the file transfer system of the 
invention also includes a credit sufficiency verifier that determines whether the local 
computer has sufficient credits to transfer each selected file. The credit sufficiency 
verifier allows the transmitter to operate only when sufficient credits are found. The 

5 sufficiency of credits is determined according to established transfer costs. 
Furthermore, the number of credits in the local machine is modified upon each 
successftil file transfer by a corresponding transfer cost. A number of available 
credits for each local computer is displayed on the local computer. 

The transmitter also includes an encryptor that encrypts selected files prior to 

1 0 transmission. The receiver also includes a decryptor that decrypts each encrypted file 
upon receipt, wherein dependent upon the policy of a service provider, the number 
of credits in the local machine may be modified at least one additional credit upon 
each successful file transfer employing encryption. 

Additionally, the file transfer system can also include a credit purchaser that 

15 requests additional credits fi-om an outside source in response to a user's request, the 
outside source validating accounting information of the user and dispensing 
additional credits if the account information is validated. 

According to a preferred embodiment, the file transfer system also includes 
a transmission error doctor that determines an amount of a file successfiilly 

20 transferred when the file being transferred has been interrupted during transmission. 
The transmission error doctor transmits the portion of the file not yet transferred 
when an error-free connection between the local computer and tiie destination 
computer is established, thereby resulting in the destination computer receiving the 
file without errors. 

25 According to a preferred embodiment, the file transfer system also includes 

a scheduler that schedules a file transfer at a time selected by a local computer user, 
thereby permitting the file transfer to occur without the presence of the local 
computer user. 

The receiver can also include a recorder that records attributes of all file 
30 transfers. In such systems, the recorder can also inform an independent certifying 
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computer of attributes of the file transfer when the file transfer is successful. The 
recorder can also inform the local computer of attributes of the file transfer when the 
file transfer is successful. Dependent upon the policy of a service provider, the 
number of credits in the local machine may be modified at least one additional credit 

5 upon each notification of file transfer attributes. 

The transmitter can simultaneously transfer files to multiple destination 
computers through separate and discrete connections to each destination computer. 
Similarly, the receiver can simultaneously receive file transfers fi'om multiple 
transmitters. Furthermore, the local computer includes a receiver capable of 

10 simultaneously receiving file transfers fi-om multiple transmitters. The transmitter is 
capable of simultaneously transferring files to multiple destination computers, such 
that the local computer can simultaneously exchange (send and receive) any number 
of files with multiple computers. 

The receiver can also include a gate keeper that selectively and automatically 

15 accepts file transfers based upon the authenticated identity of a transmitting 
computer. 

In certain preferred embodiments, the file transfer system includes an index 
generator that defines an index that can be requested by a remote computer via the 
communications pathway. The index includes at least one file of which the remote 

20 computer can request a copy via a file transfer. In such systems, the index can also 
include an associated remote computer which has exclusive access to the index. 

In certain preferred embodiments, the file transfer via the communications 
pathway occurs without logging onto any intermediate store and forward computers 
and without logging onto the destination computer. 

25 In preferred embodiments, the file transfer system may effect simultaneous 

transfer of files contained in specific destination linked directories at multiple remote 
computers by triggering file transfer initiation at the remote computers with a transfer 
request. 
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Accordingto a preferred embodiment, criteria can be invoked in creating an 
index, including (a) location in file structure, (b) file type, (c) file date & time, (d) 
embedded serial number, and (e) destination authentication codes. 

In a preferred embodiment each device includes at least a display monitor, a 

5 processor with memory, a file storage device, a keyboard, a pointing device, a 
communication interface, and graphically oriented (windows) operating system 
having drag & drop functionality. Each device operates a computer program for 
controlling system functions and a computer program for a windows operating 
environment. Each device is connected to the plurality of communication pathways, 

10 and generates a graphical user interface (GUI). Also utilized are a control module for 
controlling GUI fimctions and system communications; graphics modules that call 
or create display windows for indicating candidate files that can be transmitted 
(transmit windows), candidate personal computer destinations to which files can be 
transmitted (destination windows), and transmitted files that have been sent or 

15 received (event log window); and controls for initializing and invoking system 
operating criteria via dialog windows. 

According to a preferred embodiment, a computer data signal embodied in a 
propagation medium is provided. The signal enables a variable nvmiber of data 
transfers and includes an initial connection source code segment and a data transfer 

20 source code segment. The initial connection source code segment establishes a 
connection between two devices via predetermined listening ports, with at least one 
predetermined listening port residing within each device. The initial connection 
source code segment also dynamically assigns a first data port within a first device, 
and transmits the address of the first data port to a remaining device via the 

25 predetermined listening ports. 

The data fransfer source code segment is for each of the variable number of 
data transfer operations. The data transfer source code segment dynamically assigns 
a second data port within the remaining device. The second data port corresponds to 
the first data port within the first device. The data transfer source code segment 

30 transfers data between the connected devices via the data ports so that the data is 



wo 99/26121 PCT/US98/24373 

Page -13- 

substantially simultaneously transferred between a variable number of devices via the 
dynamically assigned data ports. Each pair of first and second data ports is 
established in response to each listening port connection. 

The initial connection source code segment may also exchange data transfer 

5 characteristics and authenticate the remaining device by verifying identifying 
information of the remaining device transmitted from the remaining device. 
Furthermore, the initial connection source code segment may include a selective 
acceptance source code segment that compares the remaining device's identifying 
information with a list of destination identities stored in the first device and prohibits 

0 ^ data transfers from devices not within the list of destination identities. In a preferred 
embodiment, each device substantially simultaneously sends and receives data to and 
from multiple devices. 

The signal may also include a retum receipt source code segment that 
generates and sends a retum receipt. The retum receipt typically includes point of 

15 origin, destination, and successful completion infomiation, and is sent from the 
device that received the data transfer to the device that transferred the data upon 
successful completion of the data transfer. 

The signal may also include a certifying source code segment that 
communicates with an independent certifying processor that verifies retum receipts 

20 for point of origin, destination, and successful completion information. The 
independent certifying processor sends verification certification to the device that 
originated the data transfer upon successful completion of the data transfer. The 
retum receipt source code segment also generates and sends a retum receipt from the 
device that received the data transfer to the independent certifying processor upon 

25 successful completion of the data transfer. 

Preferably socket data structures are dynamically managed and each data port 
is represented by a socket data structure. Further, each device may store the socket 
data stmctures in a linked list in order to manage the flow of data transfers. The 
linked list is traversed to enable substantially simultaneous data transfers. 
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The signal may also include a credit source code segment that maintains and 
monitors data transfer credits and detects each data transfer in order to deduct credit 
from a credit account after a successful data transfer. The data transfer is only 
permitted when the device initiating the transfer has sufficient credits. 
5 According to a preferred embodiment, the data transfer occurs without logging 

onto any intermediate computers other than those establishing a communications 
pathway, without logging onto the destination computer, and without intermediate 
storage of transferred data on an intervening computer. 

According to a preferred embodiment, a transmitting device includes an 
10 encrypting source code segment that encrypts selected data prior to transmission. 
Further, a receiving device includes a decrypting source code segment that decrypts 
each encrypted file upon receipt. Data transfer credits comprise a defmite number of 
credits. The number of credits in the transmitting device is modified at least one 
additional credit upon each successfiil data transfer employing encryption. 
1 5 The signal may also include a credit request source code segment that requests 

additional credits firom an external credit processor in response to a request for 
additional credits firom a device. The extemal credit processor validates account 
information of the requesting device and dispenses additional credits if the account 
information is validated. 
20 The signal may also include an index source code segment that defmes an 

index for request by remote devices via a connection. The index is associated with 
at least one destination and lists mformation representative of at least one file that the 
remote devices can request. Devices corresponding to the associated destination have 
exclusive access to the index. An index request source code segment may be 
25 provided that permits a requesting device to select a particular remote device to 
which a request for an index will be sent. The request is sent to the selected remote 
device. In response to the request, the remote device returns the index to the 
requesting device. Then, the requesting device stores the index in a storage device. 
An index transfer source code segment may also be provided that, in response to each 
30 file listed in the index being selected by the requesting device, permits the requesting 
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device to request a copy of the selected file to be transferred from the remote device. 
The remote device transfers each file in response to the request. 

The initial source code segment may also estabUsh more than one connection, 
with each connection being between two devices via a different pair of listening 
5 ports. In this case, each device selects listening ports from a predetermined range of 
available ports. 

Each device may also include a variable number of destination linked 
directories that are associated with another device. Each destination linked directory 
is a file storage area on the device. A destination linked directory management 

10 source code segment is then provided that detects storing of at least one data file in 
the destination linked directory and initiates a transfer of the detected data file to the 
associated device in response to the detection. 

The signal may also include an active connection monitoring source code 
segment, a validating source code segment, and a monitoring source code segment. 

15 The active connection monitoring source code segment periodically determines 
whether each remote device in a list of at least one remote devices is currently 
actively connected to a communications pathway accessible to a local device. The 
validating source code segment validates each remote device in the list of at least one 
remote devices that is currently actively connected to the communications pathway 

20 accessible to the local device. The monitoring source code segment defers a file 
transfer to a time when the destination device becomes actively connected to the 
communications pathway accessible to the local device if the selected destination 
device is not currently actively connected to the communications pathway accessible 
to the local device. 

25 The signal may also include a parallel polling source code segment that causes 

a local device to poll a directory on at least one of the remote devices. The directory 
is associated with an assigned destination. The local device requests all data within 
the directory to be transferred to the local device. Thus, multiple remote devices are 
substantially simultaneously polled and the data is transferred substantially 
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simultaneously to the local device from all of the remote devices. Further, the data 
transfers to the assigned destination. 

A file transfer method is provided that enables data transfers between a local 
device and at least one remote device. The method includes establishing a connection 

5 with the at least one remote device via preestablished listening ports that reside 
within each device. Furthermore, the method includes dynamically assigning a data 
port within the local device with each data port within each device enabling a data 
transfer; and transmitting the address of the data port to the remote device via the 
listening ports. The method enables transferring data between the connected devices 

10 via the data ports so that the data is substantially simultaneously transferred between 
multiple remote devices and the local device via the dynamically assigned data ports. 

The method also includes, after establishing the initial connection, receiving 
data transfer characteristics and authenticating the remote device by verifying 
identifying information of the remote device. The identifying information is 

15 transmitted fi-om the remote device. In addition there is a comparing of the remote 
device's identifying information with a list of destination identities stored m the local 
device. Data transfers fi-om devices not within the list of destination identities are 
prohibited. According to a preferred embodiment, the local device substantially 
simultaneously sends and receives data. 

20 The method may also include generating and sending a return receipt, 

including point of origin, destination, and successfiil completion information, fi-om 
a device that received a data transfer to a device that transferred data after successful 
completion of the data transfer. In addition, the method may further include 
communicating with an independent certifying processor that verifies retum receipts 

25 for point of origin, destination, and successful completion information. The 
independent certifying processor sends a verification certification to a device that 
originated the data transfer upon successful completion of the data transfer. Thus, 
the device that received the data transfer generates and sends a retum receipt to the 
independent certifying processor upon successful completion of the data transfer. 
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Preferably socket data structures are dynamically managed and each data port 
is represented by a socket data structure. Further, each device may store the socket 
data structures in a linked list in order to manage the flow of data transfers. The 
linked list is traversed to enable substantially simultaneous data transfers. 

5 The method may also include requesting additional credits from an extemal 

credit processor in response to a request from a device for additional credits. In this 
case, the extemal credit processor vaUdates accoxmt information of the requesting 
device and dispenses additional credits if the account information is validated. 

The method may also include defining an index that can be requested by 

1 0 remote devices via the initial connection. The index includes at least one file that the 
remote computer can request a copy of via the data transfer, and an associated 
destination. The associated destination is a specific destination, and devices 
corresponding to the specific destination have exclusive access to the index. The 
associated destination may altematively be a general destination, such that any remote 

15 device has access to the index. 

A requesting device may be permitted to select the remote device where a 
request for an index will be sent. When the request is sent to the selected remote 
device, the remote device retums the index to the requesting device, and the 
requesting device stores the index in a storage device. When any file listed m the 

20 index is selected by the requesting device, the requesting device requests that a copy 
of the selected file be transferred from the remote device. In response to the request, 
the remote device transfers each file. 

According to a preferred embodiment, each device may include a variable 
number of destination linked directories, each associated with another device. Each 

25 destination linked directory is a file storage area on the device or accessible to the 
device. In this case, the method also includes detecting storing of at least one data 
file in the destination linked directory and initiating a transfer of the detected data file 
to the associated device in response to the detection. 

According to a preferred embodiment, the method also includes periodically 

30 determinmg whether each remote device in a list of at least one remote device is 
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currently actively connected to a communications pathway accessible to a local 
device; validating each remote device in the list of at least one remote device that is 
currently actively connected to the communications pathway accessible to the local 
device. A file transfer is deferred to a time when the destination device becomes 

5 actively connected to the communications pathway accessible to the local device if 
the selected destination device is not currently actively connected to the 
communications pathway accessible to the local device. 

According to a preferred embodiment, the method also includes polling a 
directory on at least one of the remote devices (the directory is associated with an 

10 assigned destination) and requesting all data within the directory to be transferred to 
a local device. Thus, multiple remote devices are substantially simultaneously polled 
and data is transferred substantially simultaneously to the local device from all of the 
multiple remote devices. Further, the data transfers to the assigned destination. 

The established connection may include more than one cormection, with each 

1 5 connection being between two devices via a different pair of listening ports. In this 
case, each device selects listening ports from a predetermined range of available 
ports. 

Another file transfer method is provided that enables data transfer between a 
local device and at least one remote device. The method includes establishing a 

20 connection with the remote device via preestablished listening ports that reside within 
each device; receiving an address of a first data port from the remote device via the 
listening ports; dynamically assigning a corresponding second data port 
(corresponding to the first data port within the remote device) within the local device, 
each data port within each device enabling a data transfer; and transferring data 

25 between the connected devices via the data ports. Thus, the data is substantially 
simultaneously transferred to multiple remote devices via the dynamically assigned 
data ports. After establishing the connection, data transfer characteristics may be 
transmitted. Further each local device may substantially simultaneously send and 
receive data to and from multiple devices. 
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The method may also include generating and sending a return receipt, 
including point of origin, destination, and successful completion information, from 
a device that received a data transfer to a device that transferred data upon successful 
completion of the data transfer. In addition^ the method may further include 

5 communicating with an independent certifying processor that verifies return receipts 
for point of origin, destination, and successful completion information. The 
independent certifying processor sends a verification certification to a device that 
originated the data transfer upon successful completion of the data transfer. Thus, 
the device that received the data transfer generates and sends a retum receipt to the 

10 independent certifying processor upon successful completion of the data transfer. 

Preferably socket data structures are dynamically managed and each data port 
is represented by a socket data structure. Further, each device may store the socket 
data structures in a linked list in order to manage the flow of data transfers. The 
linked list is traversed to enable substantially simultaneous data transfers. 

1 5 The method may also include maintaining and monitoring data transfer credits 

and detecting each data transfer in order to debit a credit account after a successful 
data transfer. The data transfer is only permitted when the device initiating the 
transfer has sufficient credits. 

The method may also include requesting additional credits from an extemal 

20 credit processor in response to a request firom a device for additional credits. In this 
case, the extemal credit processor validates account information of the requesting 
device and dispenses additional credits if the account information is validated. 

The method may also include defining an index that can be requested by 
remote devices via the initial connection. The index includes at least one file that the 

25 remote computer can request a copy of via the data transfer, and an associated 
destination. A requesting device may be permitted to select the remote device where 
a request for an index will be sent. When the request is sent to the selected remote 
device, the remote device returns the index to the requesting device, and the 
requesting device stores the index in a storage device. When any file listed in the 

30 index is selected by the requesting device, the requesting device requests that a copy 
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of the selected file be transferred from the remote device. The remote device 
transfers each file in response to the request. 

According to a preferred embodiment, each device may include a variable 
number of destination linked directories, each associated with another device. Each 

5 destination linked directory is a file storage area on the device or accessible by the 
device. In this case, the method also includes detecting storing of at least one data 
file in the destination linked directory and initiating a transfer of the detected data file 
to the associated device in response to the detection. 

According to a preferred embodiment, the method also includes periodically 

10 determining whether each remote device in a list of at least one remote device is 
currently actively connected to a communications pathway accessible to a local 
device; and validating each remote device in the list of at least one remote devices 
that is currently actively connected to the communications pathway accessible to the 
local device. A file transfer is deferred to a time when the destination device 

15 becomes actively connected to the communications pathway accessible to the local 
device if the selected destination device is not currently actively connected to the 
communications pathway accessible to the local device. 

According to a preferred embodiment, the method also includes polling a 
directory on at least one of the remote devices (the directory is associated with an 

20 assigned destination) and requesting all data within the directory to be transferred to 
a local device. Thus, multiple remote devices are substantially simultaneously polled, 
and data is transferred substantially simultaneously to the local device from all of the 
multiple remote devices. Further, the data transfers to the assigned destination. 

A file transfer device is provided that transfers data with at least one remote 

25 device. The file transfer device includes at least one listening port through which a 
control connection is established with the remote device. The control connection is 
utilized to determine a remote data port for transferring data, each data port enabling 
a data transfer. At least one dynamically assigned data port is for data transfer with 
the remote data port, the data being substantially simultaneously transferred with 

30 multiple remote devices via the dynamically assigned data ports. The control 
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connection may be further utilized to exchange data transfer characteristics. Further, 
each device may substantially simultaneously send and receive data to and from 
multiple devices. 

The file transfer device may also include a return receipt system that generates 

J and sends a retum receipt. The return receipt typically includes point of origin, 
destination, and successful completion information, and is sent from the device that 
received the data transfer to the device that transferred the data upon successful 
completion of the data transfer. 

The file transfer device may also include a certifying system that 

) communicates with an independent certifying processor that verifies retum receipts 
for point of origin, destination, and successful completion information. The 
independent certifying processor sends verification certification to the device that 
originated the data transfer upon successful completion of the data transfer. The 
retum receipt system also generates and sends a retum receipt from the device that 

5 received the data transfer to the independent certifying processor upon successful 
completion of the data transfer. 

Preferably socket data structures are dynamically managed and each data port 
is represented by a socket data stmcture. Further, each device may store the socket 
data smictures in a linked list in order to manage the flow of data transfers. The 

3 linked list is traversed to enable substantially simultaneous data transfers. 

The file transfer device may also include a credit system that maintains and 
monitors data transfer credits and detects each data transfer in order to deduct credit 
from a credit account after a successful data transfer. The data transfer is only 
permitted when the device initiating the transfer has sufficient credits. The number 

5 of available credits for the device may be dynamically displayed on the device. 

According to a preferred embodiment, a transmitting device includes an 
encrypting system that encrypts selected data prior to transmission. Further, a 
receiving device uicludes a decrypting system that decrypts each encrypted file upon 
receipt. Data transfer credits comprise a defmite number of credits. The number of 
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credits in the transmitting device is modified at least one additional credit upon each 
successful data transfer employing encryption. 

The file transfer device may also include a credit request system that requests 
additional credits from an extemal credit processor in response to a request for 
5 additional credits from a device. The extemal credit processor validates account 
information of the requesting device and dispenses additional credits if the account 
information is validated. 

The file transfer device may also include an index system that defines an index 
for request by remote devices via the connection. The index is associated v^ith at 

10 least one destination and lists information representative of at least one file that the 
remote devices can request. Devices corresponding to the associated destination have 
exclusive access to the index. An index request system may be provided that permits 
a requesting device to select a particular remote device to which a request for an 
index will be sent. The request is sent to the selected remote device. In response to 

15 the request, the remote device returns the mdex to the requesting device. Then, the 
requesting device stores the index in a storage device. An index transfer system may 
also be provided that, in response to each file listed in the index being selected by the 
requesting device, permits the requesting device to request a copy of the selected file 
to be transferred from the remote device. The remote device transfers each file in 

20 response to the request. 

Each device may also include a variable number of destination linked 
directories that are associated with another device. Each destination linked directory 
is a file storage area on the device or accessible to the device. A destination linked 
directory management system is then provided that detects storing of at least one data 

25 file in the destination linked directory and initiates a transfer of the detected data file 
to the associated device in response to the detection. 

The file transfer device may also include a parallel polling system that causes 
a local device to poll a directory on at least one of the remote devices. The directory 
is associated with an assigned destination. The local device requests all data within 

30 the directory to be transferred to the local device. Thus, multiple remote devices are 
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substantially simultaneously polled, and the data is transferred substantially 
simultaneously to the local device from all of the remote devices. Further, the data 
transfers to the assigned destination. 

Another file transfer device is provided that transfers data with at least one 
5 remote device. The file transfer device includes at least one listening port that 
receives a control connection from the at least one remote device. The device also 
includes at least one dynamically assigned data port for data transfer with the remote 
device, each data port enabling a data transfer. The control connection is utilized to 
transmit the address of the at least one dynamically assigned data port. Thus, data 

1 0 may be substantially simultaneously transferred with multiple remote devices via the 
dynamically assigned data ports. The control connection may be further utilized to 
receive data transfer characteristics and authenticate the remote device by verifying 
the remote device's identifying information. The identifying information is 
transmitted from the remote device. Each device may substantially simultaneously 

15 send and receive data. 

The control connection may also include a selective acceptance system that 
compares the remote device's identifying information with a list of destination 
identities stored in the first device and prohibits data transfers from devices not 
within the list of destination identities. 

20 The file transfer device may also include a return receipt system that generates 

and sends a return receipt. The return receipt typically includes point of origin, 
destination, and successful completion information, and is sent from the device that 
received the data transfer to the device that transferred the data upon successful 
completion of the data transfer. 

25 The file transfer device may also include a certifying system that 

communicates with an independent certifymg processor that verifies return receipts 
for point of origin, destination, and successful completion information. The 
independent certifying processor sends verification certification to the device that 
originated the data transfer upon successful completion of the data transfer. The 

30 return receipt system also generates and sends a return receipt from the device that 
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received the data transfer to the independent certifying processor upon successful 
completion of the data transfer. 

Preferably socket data structures are dynamically managed and each data port 
is represented by a socket data structure. Further, each device may store the socket 
5 data structures in a linked list in order to manage the flow of data transfers. The 
linked list is traversed to enable substantially simultaneous data transfers. 

The file transfer device may also include a credit request system that maintains 
and monitors data transfer credits, and detects each data transfer in order to debit a 
credit account after a successful data transfer. The data transfer is only permitted 
10 when the device initiating the transfer has sufficient credits. A number of available 
credits for the device may be dynamically displayed on the device. 

According to a preferred embodiment, a transmitting device mcludes an 
encrypting system that encrypts selected data prior to transmission. Further, a 
receiving device includes a decrypting system that decrypts each encrypted file upon 
15 receipt. Datatransfer credits comprise a definite number of credits. The number of 
credits in the transmitting device is modified at least one additional credit upon each 
successfiil data transfer employing encryption. 

The file transfer device may also include a credit request system that requests 
additional credits fi-om an external credit processor in response to a request for 
20 additional credits fi-om a device. The external credit processor validates account 
information of the requesting device and dispenses additional credits if the account 
information is validated. 

The file transfer device may also include an index system that defines an index 
for request by remote devices via a connection. The index is associated with at least 
25 one destination and lists information representative of at least one file that the remote 
devices can request. Devices corresponding to the associated destination have 
exclusive access to the index. An index request system may be provided that permits 
a requesting device to select a particular remote device to which a request for an 
index will be sent. The request is sent to the selected remote device. In response to 
30 the request, the remote device returns the index to fiie requesting device. Then, the 
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requesting device stores the index in a storage device. An index transfer system may 
also be provided that, in response to each file listed in the index being selected by the 
requesting device, permits the requesting device to request a copy of the selected file 
to be transferred from the remote device. The remote device transfers each file in 
5 response to the request, ^ 

Each device may also include a variable number of destination linked 
directories that are associated with another device. Each destination hnked directory 
is a file storage area on the device or accessible to the device. A destination linked 
directory management system is then provided that detects storing of at least one data 

10 file in the destination linked du"ectory and initiates a transfer of the detected data file 
to the associated device in response to the detection. 

The file transfer device may also include a parallel polling system that causes 
a local device to poll a directory on at least one of the remote devices. The directory 
is associated with an assigned destination. The local device requests all data within 

15 the directory to be transferred to the local device. Thus, multiple remote devices are 
substantially simultaneously polled, and the data is transferred substantially 
simultaneously to the local device from all of the remote devices. Further, the data 
transfers to the assigned destination. 

The file transfer device may also include an active connection monitoring 

20 system that periodically determines whether each remote device in a list of at least 
one remote devices is currently actively connected to a communications pathway 
accessible to a local device; a vaUdating system that validates each remote device in 
the list of at least one remote devices that is currently actively connected to the 
conmiunications pathway accessible to the local device; and a monitoring system that 

25 defers a file transfer to a time when the destination device becomes actively 
connected to the communications pathway accessible to the local device if the 
selected destination device is not currently actively connected to the communications 
pathway accessible to the local device. 

A data file delivery system is provided for delivering data files between a 

30 variable number of devices. The data file delivery system includes a variable number 
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of peer systems. Each peer system has a connection negotiatmg system for opening 
at least one Ustening port for exchanging control data. Each peer also includes a data 
connection system for opening a variable number of data ports, each associated with 
a destination, for exchanging data files; a file selection system for selecting a variable 
5 number of data files residing on at least one peer system designated as a file source; 
and a destination selection system for selecting a variable number of destinations for 
receiving the selected data files. At least the file source has a transmitting system for 
storageless sending of the selected data files over a variable number of data 
communications pathways corresponding to the data ports. The destinations each 
10 have a receiving system for storageless receiving of the files sent via storageless 
sending. At least the file source or the destination has an initiating system for 
initiating operation of the transmitting system, via at least one communications 
negotiating pathway corresponding to the at least one listening port, fi"om either the 
file source or the destination. Each file source is also a destination having a receiving 
15 system for storageless receiving of files sent via storageless sending by at least one 
other peer system acting as a subsequent file source at the same time that the 
transmitting system operates. 

Each peer may also include a variable number of destination linked directories, 
' each associated with another device. Each destination linked directory is a file 
20 storage area on the device or accessible to the device. Each peer may also include a 
destination linked directory management system for detecting storing of at least one 
data file in the corresponding file storage area and for controlling the initiating 
system to initiate operation of the transceiver system in response to the detection. 
Each peer system may also include a return receipt system for generating and 
25 sending a retum receipt including point of origin, destination, and successftil 
completion information, fi"om each destination peer system receiving the selected 
files to the file source peer system over the storageless communications pathway 
corresponding to the data ports upon successftil completion of the storageless 
receiving of the selected files. 
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The system may also include a third party transaction certificate processor for 
examining and verifying return receipts for point of origin, destination, and 
successful completion information. The third party transaction certificate processor 
is also for sending verification certificate data files over a first additional storageless 

5 communications pathway corresponding to a first additional data port to the file 
source peer system upon successful completion of the storageless receiving of the 
selected files. The return receipt system generates and sends a retum receipt fi-om 
each destination peer system receiving the selected files to the third party transaction 
certificate processor over a second storageless communications pathway 

10 corresponding to a second additional data port upon successfiil completion of the 
storageless receiving of the selected files. 

Each peer system may also include a file credit monitoring system for 
maintaining and monitoring file delivery credits. The file credit monitoring system 
detects each storageless sending of selected files and debits a credit account variable 

15 on an associated peer system in accordance with a function based on the storageless 
sending. The system may also include a credit processor for receiving credit requests 
and for incrementing a credit account variable on an associated one of the peer 
systems upon receipt of a credit request and successful comparison of the credit 
request against a credit authorization function. The file credit monitoring system 

20 generates and sends a credit request from one of the peer systems to the credit 
processor. 

Each peer system may also include an index generating system for generating 
an index of files on a peer system; an index requesting system for requesting and 
retrieving an index of files fi-om any one of the variable number of peer systems; a 
25 subset selecting system for selecting a subset of a variable number of files from the 
retrieved index of files from any of the variable number of peer systems; and a file 
subset requesting system for initiating operation of the transceiver system to transfer 
the subset from any one of the variable number of peer systems to the peer system. 
Each peer system may also include a transceiver management system for 
30 managing substantially parallel and simultaneous operation of a variable number of 
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transceiver systems for substantially parallel and simultaneous storageless sending 
and storageless receiving of the selected files over a plurality of communications 
pathways corresponding to a plurality of data ports. 

The data transfer via the communications pathway occurs without logging 

5 onto any intermediate computers other than those needed to establish the 
communications pathway, without logging onto the destination computer, and 
without intermediate storage of transmitted files on an intervening computer. The 
connection with the destination via the data port is to a destination address received 
with the control data. According to a preferred embodiment, when a file is saved to 

10 a predetermined directory associated with a destination, the file is transferred to the 
destination. 

Another file transfer system is provided for transferring files between at least 
one local computer and at least one remote computer selected from a list of at least 
one remote computers, across at least one communications pathway. The file transfer 

15 system includes a file selector that selects at least one file stored on the local 
computer for transferring to the at least one remote computer; a destination selector 
that selects, from the list of at least one remote computers, at least one remote 
computer designated as a destination computer to which the file will be transferred; 
a transmitter that transfers the selected file to the destination computer via the 

20 communications pathway without storing the selected file on any intermediate 
computers; and a receiver that receives the transferred file. 

The system also includes an initial connection system that establishes a 
connection between the local computer and the destination computer via 
predetermined listening ports. At least one predetermined listening port resides 

25 within each computer. Data transfer characteristics are exchanged during the initial 
connection. The identities of the local and destination computer are authenticated by 
verifying each computer's identifying information. 

The system also includes a first allocator that dynamically assigns a first data 
port represented by a socket data structure within the destination computer; a first 

30 transmitter that transmits the address of the first data port to the local computer via 
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the predetermined listening ports; a second allocator that dynamically assigns a 
second data port represented by a socket data structure within the local computer 
corresponding to the first data port within the destination computer, each pair of first 
and second data ports being dynamically assigned in response to each listening port 
5 connection; and a second transmitter that transfers data between the connected 
computers via the data ports. The data is substantially simultaneously transferred 
between a variable number of computers via the dynamically assigned data ports. 
Each computer is capable of substantially simultaneously sending and receiving data. 
Each computer dynamically manages socket data structures to enable substantially 

10 simultaneous data transfers. 

The system also includes a generator that generates and sends a return receipt, 
including point of origin, destination, and successful completion information, from 
the computer that received the file transfer to the computer that transferred the file, 
and an independent certifying processor upon successful completion of the file 

15 transfer. 

The system also includes a third transmitter that communicates with the 
independent certifying processor that verifies return receipts for point of origin, 
destination, and successful completion information. The independent certifying 
processor sends verification certification to the computer that originated the file 

20 transfer upon successfiil completion of the file transfer. 

The system also includes a credit system that maintains and monitors file 
transfer credits and detects each file transfer in order to debit a credit account after 
a successful file transfer. The file transfer is only permitted when the computer 
initiating the transfer has sufficient credits. 

25 The system also includes a credit request system that requests additional 

credits from an extemal credit processor in response to a request from a computer for 
additional credits. The extemal credit processor validates account information of the 
requesting computer and dispenses additional credits if the account information is 
validated. 

30 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is further described in the detailed description which 
follows, by reference to the noted drawings by way of non-limiting examples of 
preferred embodiments of the present invention, in which like reference numerals 
5 represent similar parts throughout several views of the drawings, and in which: 

Figure 1 is a schematic block diagram illustrating a system architecture with 
a limited number of personal computers connected to various communication 
pathways, according to an aspect of the present invention; 

Figure 2 is a flow diagram of exemplary logic of a main control module which 
10 controls automated functions and user invoked functions accessed through a 
graphical user interface, according to an aspect of the present invention; 

Figures 3 A and 3B are flow diagrams of exemplary logic of a send file module 
which controls the file transmit functions, according to an aspect of the present 
invention; 

15 Figures 4A, 4B and 4C are flow diagrams of exemplary logic of a receive file 

module which controls the receive file fimctions, according to an aspect of the 
present invention; 

Figure 5 is a flow diagram showing exemplary logic for confmnation receipt 
request processing, according to an aspect of the present invention; 
20 Figure 6 is a flow diagram of exemplary logic of a create index module which 

creates an index of files that the user wishes to make available for request from 
another PC, according to an aspect of the present invention; 

Figure 7 is a flow diagram of exemplary logic of a request file module which 
creates a request file pending event in the main control module, according to an 
25 aspect of the present invention; 

Figure 8 is a flow diagram of exemplary logic of a return requested file 
module which processes requests for one or more files, or an index, and creates 
pending events to return the requested files or indexes in the main control module, 
according to an aspect of the present invention; 
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Figure 9 is a flow diagram of exemplary logic of a request credits module 
which collects accounting information and the number of file transmissions to be 
authorized, and creates an authorization request pending event in the main control 
module, according to an aspect of the present invention; 
5 Figure 10 is a flow diagram of exemplary logic of a credits request processing 

module which operates on a credit server, according to an aspect of the present 
invention; 

Figure 11 is a flow diagram of exemplary logic of an add credits module 
which increments any remaining credits by the amount of the new authorized credits, 
1 0 according to an aspect of the present invention; 

Figure 12 is a flow diagram of exemplary logic of a remove credits module 
which decreases credits by the amount of the transfer cost, according to an aspect of 
the present invention; 

Figure 13 is a flow diagram of exemplary logic for a check for active 
15 connections module which periodically checks for active cormections for each 
address listed in the destination window, according to an aspect of the present 
invention; 

Figure 14 is a flow diagram showing exemplary logic for a third party 
authenticatofs processing of confirmation receipt requests, according to an aspect of 
20 the present invention; 

Figure 15 shows an example of an event log window which records file 
transmission and receipt events^ according to an aspect of the present invention; 

Figure 16 illustrates an example of an event properties window that shows the 
properties and listed files of events listed in the event log file, according to an aspect 
25 of the present invention; 

Figure 17 illustrates examples of the . transmit window for selecting files to 
transfer, and the destination window for selecting destinations to transfer the file to, 
according to an aspect of the present invention; 
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Figure 18 shows an example of an add/edit destination window for adding and 
editing the destination addresses in the destination window, according to an aspect 
of the present invention; 

Figure 19 shows an example of a select destination window for selecting the 
5 destination for the file transfer and initiating the file transfer, according to an aspect 
of the present invention; 

Figure 20 shows alternative examples of a transmit window for selecting files 
to transfer, and the event properties window that shows the properties and listed files 
of events listed in the event log file, according to an aspect of the present invention; 
10 Figure 2 1 shows alternative examples of a transmit window for selecting files 

to transfer, and the event properties window that shows the properties and hsted files 
of events listed in the event log file, according to an aspect of the present invention; 

Figure 22 shows an example of a build index window for creating the index 
of files that can be requested by a destination PC, according to an aspect of the 
15 present invention; 

Figure 23 shows an example of a request file window for requesting files fi-om 
another PC, according to an aspect of the present invention; 

Figure 24 shows altemative examples of a transmit window for selecting files 
to transfer, and the destination window for selecting destinations to transfer the file 
20 to, along with a transport credit bar and credit request button, according to an aspect 
of the present invention; and 

Figure 25 is a flow diagram of exemplary logic of a send file scheduling 
module, according to an aspect of the present invention. 

DETAILED DESCRIPTION OF 
25 PREFERRED EMBODIMENTS OF THE INVENTION 

Referring now to Fig. 1, there is shown a schematic illustration of one 

preferred embodiment of the present invention illustrating a system architecture with 

a limited number of personal computers (PCs) 10 connected to communications 

pathways, even though any number of PCs 10 may be connected without limitation. 

30 Fig. 1 shows that the PCs 10 may be connected to and may use one communications 

pathway (e.g., the Internet), another communications pathway (e.g., the public 
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switched telephone network PSTN), or more than one communications pathway (e.g., 
Internet and PSTN) simultaneously. The preferred embodiment of Fig. 1 includes 
multiple PCs 10, without limitation as to the maximum number of PCs 10. Although 
each PC 10 is shown to be connected to the Internet, and/or the PSTN, alternative 

5 communications pathways may be employed, such as private intranets and extranets. 

Each PC 10 is preferably, but is not limited to, an "IBM compatible" x86 or 
Pentium class machine, connected to a communications pathway. However, other 
computing devices, such as hand held computers, television set top boxes, mobile 
telephones, wearable computers, wireless computing devices, or any other device 

1 0 capable of connecting to a network and utilizing an operating system may be utilized. 
Of course, computers more advanced than Pentium class can be utilized as well. 
Each PC 10 can include a display monitor, a processor, memory such as ROM and 
RAM, a file storage device, a keyboard, a pointing device, a communication 
interface, and a graphic user interface GUI operating system having "drag & drop" 

15 fiinctionality. Preferably, the operating system is Microsoft Windows NT, Windows 
95, Windows 98, or Windows 3.1x, all available from Microsoft Corp. However, the 
operating system may be any other graphically oriented operating system such as Mac 
OS available from Apple Computer, Inc., Solaris, Xwindows, etc. 

Each PC 10 runs a computer program incorporating fimctional modules, such 

20 as those illusfrated m Figs. 2-9 and 1 1 - 1 3, and has a GUI consisting of windows, such 
as those illusfrated in Figs. 15 through 24 described below. The file transfer system 
shown in Fig. 1, including the PCs 10 running the computer program and graphical 
user interface, enables direct fransfer of electronic files between such interconnected 
PCs 1 0 without requiring login to each other PC 1 0, and without intermediate storage 

25 of files on an intervening computer. A credit request processor 16 and independent 
certification processor 18 may also be provided and are discussed in detail below. 

The GUI is generated by a computer program designed for a windowed 
operating environment such as Microsoft Windows. The GUI consists of modules 
for controlling system communications and fimctions accessed from the GUI, and 

30 graphics modules that call or create display wmdows. Exemplary display windows 
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include a transmit window for indicating candidate files that can be transmitted, a 
destination window displaying candidate PC destinations to which files can be 
transmitted, and an event log window that displays transmitted files that have been 
sent or received. Furthermore, the GUI provides user controls for initializing and 

5 invoking system operating criteria via dialog windows. 

In greater detail, the following describes the operating functions of a preferred 
embodiment of the computer program and graphical user interface of the present 
invention from the perspective of both the sending PC and the receiving PC. 
Although the description is in terms of software, the present invention can also be 

10 implemented with firmware, a combination of hardware and software, or with only 
hardware such as a with a fixed fimction machine or application specific integrated 
cu-cuits, etc. In order to effect a file transfer, the computer program of a preferred 
embodiment of the present invention must be operating on both the sending PC and 
the receiving PC during the time communication is attempted. Other required 

1 5 operating conditions include active connection to the Internet, intranet or extranet, or 
a modem connection to the PSTN; "power-on" or standby state at both the sending 
and the receivmg PC; and a windowed operating system such as Microsoft Windows 
NT, Windows 95 or Windows 3.1 installed and operatmg on both the sending PC and 
the receiving PC. 

20 In a preferred embodiment, control modules govern and supervise the 

transmission and receipt of files across the connected communications pathway. 
Moreover, a transmit window displays a list of files stored on the file storage device. 
When files displayed in the transmit window are selected then dragged & dropped on 
to a graphical object, the drag & drop fimction of the windowed operating system 

25 internally creates a list of files with an associated file structure. The internal list is 
then linked by the operating system to the destination object represented by the 
graphical object. 

In a preferred embodiment, each candidate PC destination is displayed as a 
user created "nick name" in a destination window. Still fiirther, each nick name may 
30 be a graphical object, invoked by the user, generated by a computer program module 
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and linked to a destination address (either IP address or PSTN number), and a 
computer program subroutine. When files are dragged and dropped onto the 
destination object in the destination window, a file list with associated file structure 
is created by the windowed operating system and a control module displays a dialog 

5 box prompting the user for confirmation that the selected files contained in the file 
list are to be transmitted to the destination selected. 

In a preferred embodiment, after the user confirms the files to be transmitted, 
a compression control module calls a compression subroutine that copies and 
compresses the files contained in the file list, and stores the compressed file packet 

10 on the PC's file storage device. In the context of this specification, a "file packet" is 
preferably a grouped and compressed assembly of files, rattier than a multiplexing or 
fi-ame-transmission "packet". Then, the control module sends a packet file name and 
the address linked to the selected destination object to a pending event log file. 

Later, at a predetermined time, a control module initiates a connection with the 

1 5 destination PC via an appropriate communications pathway, identifies the sending PC 
by its name arid destmation address, then transmits the packet containing the 
compressed files to the linked destination address across the connected 
communications pathway. The control module then indicates in an event log window 
by date, time, and content (which may include file names and associated file 

20 structure), when the transmission of the packet is complete. 

The predetermined time is selected by the user. Thus, after selecting a file to 
send, the user may schedule the transfer to occur immediately, or at a later tune 
and/or date. If the file transfer is scheduled for later, the packet file name and 
destination address remain in a pending event log file until the designated date and 

25 time. - 

In preferred embodiments, a control module responds to inbound file 
transmissions, captures, decompresses, and writes transmitted files to the computer 
file storage device using the associated file structure, and creates a received file list 
that is linked to the stored files and displayed in the event log window showing date, 

30 time and content Still fiirther, the control module initiates a continuous sequence for 
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visibly indicating when a packet has been received by a destination PC. Preferably, 
user selection of the received file listed in the event log window launches any 
apphcation that has been associated with the file type received. 
System Control: Figure 2 & Figure IS 

5 According to a preferred embodiment of the present invention, the computer 

program and graphical user interface operating on each interconnected PC 10 
provides for system control and user interaction. A main control module, illustrated 
in Fig. 2, is provided for controlling automated system functions as well as functions 
accessed through the graphical user interface 1. When the user activates the 

10 computer program through the graphical user interface 1, the main control module 
initializes system variables and links DLL files required for system operation at step 
.S2. 

A DLL is a dynamic link library and is a standard Microsoft Windows 
convention for storing functions called by application programs. DLLs can be part 
15 of the Windows operating system, application program interfaces (APIs) from 
software vendors, or functions vmtten for a specific application. Table 1 illustrates 
exemplary DLLs for the present invention and their purpose. 
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Table 1 



Type: 


Purpose: 


Windows standard dlls 




user 


GUI interface 


shell 


Drag and drop support 


kernel 


File and memory functions 


Toolbox functions 




tb50dos.dll 


File and directory support 


tb50win.dll 


High level GUI support 


tb50dlg.dll 


Common dialog functions 


Third Partv APIs 




saxcom lO.dll 


Modem file transfer functions 


compress. dll 


Compression functions 


Custom DLLs 




adis.dll 


Destination book functions 




Indexing functions 


hyper.dll 


Log functions 


ftpip.dll 


Internet file transfer functions 



20 Saxcom lO.dll is available from Sax Software Corporation of Eugene,. Oregon 

and implements several file transfer protocols for use with analog telephones, 
including Zmodem. 

Operation of the main control module in each PC 10 is centered on a pending 
events file. The pending events file contains a Ust of events initiated by user 

25 interactions or communication requests from other interconnected PCs 10. At step 
S3 the main control module monitors the contents of the pending events file to 
determine if any pending send events exist. If pending send events are detected, at 
step S4 the main control module calls a send file module, described below with 
reference to Fig. 3. After the send file module executes at step S4, or if no pending 

30 send events are detected at step S3, the pending event file is again monitored to 
determine if any pending receive events are present at step S5. If pending receive 
events are detected at step S5, the main control module calls a receive file module at 
step S6, described below with reference to Fig. 4. Otherwise, or after the receive file 
module executes, at step S7 user events are processed. 

35 User events originate in response to user interaction with control windows 

provided by the graphical user interface 1, and resulting computer program functions 
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initiated by such user interactions. An exemplary user event is scheduling a file 
transfer of a user selected file. Exemplary events are shown to originate fi-om 
modules 2-7 shown in Fig. 2. Each module 2-7 is invoked firom the graphical user 
interface 1. Processing the user events involves executing module specific logic and 

5 is described below. 

At step S9, intemet protocol (IP) connections are checked by a fimction 
described below with reference to Fig. 17. Subsequently, the logic retums to step S3 
and repeats as described above. 

Referring to the display screen shovra in Fig. 15, both completed and pending 

10 events 24 can be viev^ed in an event log window, such as tiiat shown in Fig. 15. 
Furthermore, file transfers are logged recording the date, time, and content of the 
transfer at both the sending and receiving PCs. Clicking on each tab 20 at the top of 
the event log window displays all events having the selected property indicated on the 
selected tab (e.g., failed, pending, etc.). The Decrypt button 21 launches a fimction 

15 (described below) which decrypts received files that were encrypted by the sender. 
Decryption can also be implemented without manual inter\^ention depending on the 
functionality of encryption/decryption programs integrated into the file transfer 
system. The Close Log button 22 closes the event log window. Preferably, the 
contents of the event log window includes for each event: the sender and receiver of 

20 the file, the time and date the file transfer occurred, whether the event was a send 
event or a receive event, and the status of the file transfer. Exemplary file transfer 
statuses are: completed transfer, pending transfer and failed transfer. An additional 
symbol e.g., R or U, may be displayed to indicate whether a file has been read. When 
employing the additional symbols R signifies the file has been read, and U signifies 

25 that the file has not been read. 

File Transfer System: See Figure 3 and Figure 4 

A major aspect of the present invention is the file transfer system. There are 
several parts to such a system. The first is the Windows Sockets system. In the 
present invention, to send a file fi^om one interconnected PC to another, each PC must 

30 be able to detect communication requests for other PCs. A preferred system for 
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detecting communication requests requires each PC to create at least orie data 
structure, called a socket, that listens for communication requests at a specific port 
on each PC. In a preferred embodiment, one listening port is created at port 789. 
However, any port or ports can be utilized, as long as all versions of the computer 

5 program on each interconnected PC recognize and connect to the ports used to initiate 
a transfer. As a result of the established socket, each PC listens continuously for a 
communication request from another PC. 

In a preferred embodiment, a PC connection to the Intemet or private intranets 
and extranets using TCP/IP is established by invoking subroutines which create data 

10 structures called sockets that enable communication using TCP/IP standards. A 
listening socket is established that permits the PC to monitor the Intemet, intranet or 
extranet for inbound communication requests initiated by other PCs. When an 
inbound communication request is detected, a control module in the receiving PC 
evaluates the request within the context of selective acceptance criteria prior to 

15 accepting receipt of the communication request. In other words, the receiving PC 
automatically decides whether it will accept communication from the sending PC 
based on criteria such as authenticated identity. The receiving PC terminates 
transmissions from unauthorized PC destinations. 

The selective acceptance criteria is established during system initialization. 

20 The receiving PC evaluates whether it will accept a request according to various user 
defined criteria. For example, the receiving PC may examine the addresses in the 
destination file and accept communication only from addresses listed in the 
destination file. Alternatively, the receiving PC may only allow receipt of 
communications from PCs using software having selected serial numbers. For 

25 example, license codes initialized during setup at each system PC can be utilized 
automatically in conjunction with the destination addresses to fiirther authenticate the 
source identity for inbound communication requests. Altematively, encrypted 
authentication codes initialized during setup at each system PC can be utilized in 
conjunction with the destination addresses and/or license codes to further authenticate 

30 the source identity for inbound communication requests. The user may configure the 
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acceptance criteria at installation and may change the acceptance criteria at any time 
thereafter. 

In preferred embodiments, if a control module at the receiving PC accepts the 
communication request from a sending PC, a separate socket is established by control 

5 modules at both the sending and receiving PCs. The.file transfer is via the separate 
sockets. Meanwhile, the listening sockets at both the sending PC and the receiving 
PC are maintained. As communication requests from sending PCs are detected and 
accepted by PCs engaged in sending or receiving one or more concurrent and ongoing 
transmissions, multiple sockets enabling simuhaneous file transfers are created by a 

10 control module at each PC receiving such communication requests. In preferred 
embodiments, a control module in a sending or receiving PC creates and places in 
a linked list one file transfer socket for each additional, concurrent inboimd or 
outbound communication. This list facilitates managing the flow of file transfers. 
Thus, multiple discrete connections can be established with multiple remote 

15 computers across the various communications pathways to which the local computer 
is connected. 

The process of sending a file is now described with reference to Fig. 3. 
Initially at step S30, it is determined whether sufficient credits exist for transferring 
the file. The credit sufficiency analysis is described below.. If insufficient credits are 

20 found, at step S32 additional credits may be requested as described below. If 
sufficient credits are found, at step S34 it is determined whether the transfer is 
intended to be an Intemet (or intranet/extranet) transfer. 

If the transfer is an Intemet transfer, at step S36 another socket is created. In 
addition, the sending PC connects to the listening socket on the remote PC at port 

25 789. When another transmission is already executing, the newly created socket is 
added to the linked list of sockets in use. The program traverses the list, giving 
sockets time to perform their actions. Thus, multiple transactions can occur 
substantially simultaneously. In practical terms, the number of transactions that can 
be handled by the system depends on factors such as communications speed and 

30 processor time and speed. 
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At step S3 8 it is determined whether the connection to the remote PC is 
successful. If the connection has not been established, at step S40 it is determined 
whether the sending PC previously attempted to connect to the remote PC. If a 
previous attempt occurred, it is determined whether a maximum number of attempts 

5 have occurred; in a preferred embodiment three attempts. Thus, if three unsuccessful 
attempts occurred (any number can be specified), at step S46 the logic terminates 
execution and an error is logged indicating that a connection carmot be established 
with the remote PC. Alternatively, the local computer may be setup to delay the file 
transfer until the remote destination computer has an active connection to the 

1 0 communications pathway at a known address. If the number of attempts is less than 
the maximum number of attempts allowed, the sending PC again attempts to connect 
to the remote PC at step S3'6. 

If the connection is successfully established, at step S42 the sending PC sends 
information about the file to be sent and about the sending PC, thus informing the 

15 remote PC of where the transmission is originating. The sending PC then waits for 
the remote PC to send an address to which the file can be sent. If the data received 
from the remote PC corresponds to a valid data port assignment, the logic proceeds 
to step S48. Otherwise the logic proceeds to step S46 where the logic terminates 
execution and an error is logged mdicating that an invalid reply was received. 

20 At step S48 upon receiving a valid data port assignment, a new data socket is 

created and a connection is established between the new data socket and a data port 
corresponding to the data port assignment received from the remote PC. In addition, 
a time-out timer commences and the startmg point of the file is determined. When 
another transmission is already executing, the newly created data socket is added to 

25 a linked list of data sockets. 

At step S50 data is sent to the remote PC. In a preferred embodiment, the file 
being transferred is transmitted 2048 bytes at a time. Thus, the first 2048 bytes are 
transmitted at step S50. Each time data is sent at step S50, the time-out is reset to 
zero. If the time-out reaches a maximum time, the connection is terminated and the 

30 data socket is destroyed. 
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At step S52 it is preferably determined whether other data sockets exist in the 
data socket linked list. If other data sockets exist, at step S54 data associated with the 
next data socket is sent, and the logic repeats from step S52 until no other data 
sockets are found. 

5 At step S56 it is determined whether the end of the file has been reached. If 

the end of the file has not been reached, the logic returns to step S50 and repeats. If 
the end of the file has been reached, at step S58 the connection is terminated, the data 
socket is destroyed, and the remove credits module is called. Finally, at step S60 the 
event is recorded in the log file. 

1 0 A preferred embodiment of the present invention utilizes a single designated 

User Datagram Protocol (UDP) command port to exchange file characteristic 
information, user authentication information, and to initiate a transfer. Subsequently, 
a TCP data port is opened to exchange the file content. The UDP command port 
allows faster connections and quicker data transfer than a TCP port. However, a 

15 TCP port is more reliable for data exchange. Consequently, a preferred process for 
sending a file is as follows: 

1) A sender initiates a transfer by sending file characteristic information and 
sender identification/authentication information to a specified UDP command port 
on a destination computer at a specific IP address. If the transfer is accepted, a data 

20 port is created randomly within a range of possible specified ports and its number is 
returned on the UDP connection. Otherwise, a notification that the transfer is 
rejected is sent, and the UDP connection is closed. Finally, the UDP conmiand port 
waits for new transfers to be initiated. 

2) If the transfer is accepted by the recipient, the sender connects to the TCP 
25 data port returned by the recipient over the UDP connection and starts sending the 

file. Both the recipient and sender resume "listening" on the UDP port for transfers 
initiated by other computers. This is accomplished while the file transfer over the 
TCP port is m progress. The process is repeated and managed for any number of 
subsequently initiated file transfers. Thus, multiple, simultaneous file transfers can 
30 be accomplished with any number of other computers, with only one instance of the 
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computer program open and running. Advantages of the present invention include 
a simple user interface and operating approach, great efficiency in system resource 
utilization, and fast file transfer speed. 

, 3) The receiver closes the connection when the file size information 

') (characteristic) sent over the UDP connection that initiated the transfer matches the 
size of the file received or the sender closes its connection due to an error. 

In other preferred embodiments of the invention, more than one UDP 
command port listens for or initiate file exchanges. To initiate a transfer, a sender PC 
randomly and automatically selects the UDP port from a set of specified ports. For 

) example, one, two, or more UDP ports at predetermined port numbers could be 
designated as listening ports. A sender PC initiates a file exchange on a UDP port 
randomly selected from the set of specific listening ports. The recipient monitors the 
set of specified ports for initiated file transfers and responds on the UDP port utilized 
by a prospective sender to acknowledge the connection and retum a designated data 

5 port. This configuration also lowers the probability of a "collision" in the event that 
two or more computers attempt to communicate with the same PC at exactly the same 
time. Alternatively, if such collisions did occur, the attempted communication can 
be automatically retried at a random interval later in time. 

If the file transfer is determined to be a PSTN transfer at step S34, at step S62 

d the sending PC dials the telephone number associated with the remote PC. At step 
S64 it is determined whether a connection has been successfijlly established. If no 
connection was established, the logic proceeds to step S40 where it is determined 
whether a connection attempt occurred previously. If a previous attempt occurred, 
it is determined whether a maximum number of attempts have occurred; in a 

5 preferred embodiment three attempts. Thus, if three unsuccessfiil attempts occurred, 
at step S46 the logic terminates execution and an error is logged indicating that a 
connection cannot be established with the remote PC. However, if the number of 
attempts is less than the maximum number of attempts allowed, the sending PC again 
attempts to connect to the remote PC at step S62. 
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Afler the connection is established handshaking occurs, and at step S66 the 
sending PC sends an identifier and waits for a response from the remote PC. At step 
S68 if a response is not received, at step S46 the logic terminates execution and an 
error is logged. If a response is received, at step S70 the sending PC sends file and 
5 station information to the remote machine. Then, the sending PC waits for a reply 
firom the remote PC. If no reply is received, at step S46 the logic termmates 
execution and an error is logged. Once the reply is received, at step S74 the file is 
sent to the remote PC utilizing a file transfer protocol. In a preferred embodiment, 
Zmodem is the file transfer protocol. Upon completing the file transfer, the 
10 connection is terminated. Subsequently, the transfer status of the sent file is logged, 
and the logic proceeds to step S58 to continue as previously described. 

The logic which executes at the remote/receiving computer is now described 
with reference to Fig. 4. Initially at step 400 it is determmed whether the transfer will 
be an Internet (or intranet/extranet) transfer. If the transfer is expected to be an 
15 Internet transfer, at step 402 a socket is created on port 789 and the receiving PC 
waits for a connection. When someone connects, at step 404 all sent data is read. 
Then, at step 406 the received data (i.e., ID) is compared to IDs within a destination 
book of IDs from which transfers will be accepted. If the received ID is not found 
in the destination book, at step 410 an error occurs and the connection is termmated. 
20 If the ID is found at step 408, at step 4 12 it is determined whether the received data 
is valid. If the data is not valid, at step 410 a negative acknowledgment is sent to the 
sending PC and the coimection is terminated. 

If the data is valid, at step 414 it is determined if the received data indicates 
an index or file request. If the received data indicates an index or file request, at step 
25 415 the request is processed. Otherwise, at step 416 it is determined whether the 
received data indicates a credit authorization. If the data indicates a credit 
authorization, at step 418 transmission credits are added, described in greater detail 
with reference to Fig. 11. Otherwise, at step 420 it is determined whether the 
received data indicates a request for identification. If the received data indicates a 
30 request for identification, at step 422 a response is sent to the requesting PC with the 
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ID of the receiving PC. Otherwise it is determined whether the received data is a 
partial file at step 424. 

The partial file determination occurs to decide whether an interrupted transfer 
is being resumed, or whether a new transfer is beginning. Thus, if the received data 

5 is a partial file, at step 426 a starting point is set to the size of the partial file because 
part of the file must be resent. In other words, the receiving machine informs the 
sending machine of where to resume the transmission depending on what portion of 
the file was previously received. Subsequently, at step 430 a socket is created on a 
random port, the random port address is sent to the sending PC, and a time-out timer 

10 is set If the received data is not a partial file, i.e., a new transfer is beginning, at step 
428 the starting point is set to zero. Subsequently, the logic proceeds to step 430. 

From step 430, the logic proceeds to step 432 where the receiving PC waits 
for data on the port. When data is received, the time-out counter is again reset. 
Preferably, there is an automatic visible indication of receipt of files at the receiving 

15 PC. At step 434 it is determined whether other sockets exist. If other sockets do 
exist, at step 436 data is received for the next socket. Subsequently, the logic retums 
to step 434 and repeats until no other sockets are found. Similar to the sending PC, 
the data sockets may be stored on the receiving PC in a linked list. 

At step 438 it is determined whether a file transfer is complete or if data times 

20 out. If the data times out, the connection is terminated and the socket is destroyed. 
Also, if the connection terminated on its own, the socket is destroyed. If no transfer 
is found to have completed, the logic retums to step 432 and repeats. When a file 
transfer is complete, at step 440 it is determined whether the received file is the same 
size as e?q)ected. In other words, the file size is compared to the size indicated in the 

25 file data sent at step S42. If the sizes do not coincide, at step 442 a receive error is 
logged. Otherwise, if the file sizes are the same, transmission is deemed successful 
and the logic proceeds to step 444. 

At step 444 the event received is logged, the packet is unpacked, and the 
received files are stored on the receiving PC*s storage device. Although in the 

30 previous description the sending PC is identified, by name and IP address, to the 
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receiving PC upon initial connection, the identification can come at a later time. 
However, preferably the sending PC is identified to the receiving PC before the 
receiving PC opens the received files. Next, at step 446 logic described with 
reference to Fig. 5 executes to process confirmation receipt requests. Subsequently, 
5 the logic proceeds to step 448. 

At step 448 it is determined if any other data sockets exist. If additional data 
sockets are found, the logic returns to step 432 and the processing repeats. If no other 
data sockets are found, the logic flows to step 450 where an automatic update process 
executes. 

10 Verifying the data is handled by the TCP/IP protocol that underlies the 

Windows Socket specification. Because the TCP/IP protocol handles sending and 
receiving data, file verification is automatic. That is, TCP/IP is an error responsive 
protocol that checks each TCP packet using cyclic redundancy checking (CRC) amd 
retransmits bad packets. Accordingly, if a file is assembled fi-om successfully 

1 5 received TCP packets, the probability that the received file is error-fi-ee is very high. 
Thus, it is only necessary to verify whether the entire file was received. This is 
accomplished by verifying that the size of the data transmitted matches the specified 
size of the file that is received. The file size specification is sent with the file being 
transmitted and arrives at the receiving PC at the beginning of the transmission. 

20 For modem transfers, the process is different. Thus, if the transfer is 

determined not to be an internet transfer at step 400, at step 460 the modem is set to 
auto answer mode, so that it will answer if called. Preferably the modem is set to 
auto answer mode during initialization at step S2 on each PC. 

After the modem is initialized, at step 462 the receiving PC waits for a 

25 telephone call. Upon receiving a call, the receiving PC answers and reads a data 
stream firom the modem to determine the sending PC identifier. If no data is received 
before a time out occurs, the connection is terminated. If data is received, the 
receiving PC sends a response to the sending PC, which includes an identifier of the 
receiving PC. 
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At step 464 file data validity is checked. If the data is invalid, a receive error 
is logged at step 442. Otherwise if the data is valid, at step 466 the download 
commences with an agreed upon model protocol, preferably, Zmodem that checks 
each packet using CRC and retransmits bad packets. Subsequently, the logic 

5 proceeds to step 468 to determine whether the received file is the same size as 
e?q3ected, indicating a successfiil transfer. If the file is not the expected size, at step 
442 a receive error is logged. If the received file is the expected size, at step 470 a 
receive event is logged, and the received packet is unpacked and stored on a storage 
device. Next, at step 472 logic described with reference to Fig. 5 executes to process 

10 confirmation receipt requests. Subsequently, the logic proceeds to step 450 and 
executes as previously described. 

By using the Zmodem protocol, error checking is automatic. However, once 
again the file size is checked to ensure that the received file is the size it is supposed 
to be. 

15 Confirmation Receipt Request and Third Party Authentication: See Figure 5 & 
Figure 14 

According to another preferred embodiment, the present invention enables a 
sending PC to request fi-om a recipient PC, confirmation of the attributes of a 
transferred file packet. The confirmation is a retumed file containing a received file 

20 list, along with the identity of both recipient and sender, as well as various other 
attributes. The receipt file is retumed fi-om the recipient to the sender directly or 
through a third party authenticator 18 (Fig. I) without requiring any action by the 
recipient computer's user. The sender may designate whether confirmation is by 
direct retum or through a third party authenticator 18 common to all users. The 

25 destination address of the third party authenticator 18 is either incorporated into the 
computer program prior to distribution to users or entered by a user prior to initiating 
the confirmation requests as part of setup of the computer program on the sending 
PC. 

A control module on the recipient PC, upon receipt of a request for a 
30 confirmation of the attributes of a transferred file packet, records the content of the 
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received packet. This may be set up to occur before or after it is decrypted and 
decompressed. By creating a file list, the content files are written into the file 
structure of the recipient computer's storage device. Still further, the control module 
on the recipient PC combines into a confirmation receipt file attributes of the 
5 transferred file packet. The attributes may include (1) a file list that delineates the 
names of files actually found to be present in a received packet, whether containing 
encrypted or unencrypted files, (2) the size of the files received, (3) the identity of the 
sending PC (point of origin) as received with the file packet, (4) the identity of the 
recipient PC, (5) the date of packet receipt, (6) the time of packet receipt, and (7) the 
1 0 electronic fingerprint (hash) of the transmitted files. Alternatively, the confirmation 
receipt may be setup to provide only verification of a file transfer action 
accomplished at a specific date, time, and destination. 

Still further, if direct return has been requested by the sending PC, the control 
module on the recipient PC creates a pending event for immediate return of the 
1 5 confirmation receipt file to the sending PC, designating the corresponding destination 
address. Moreover, if the requested confirmation is designated by the sender to be 
retumed through a third party authenticator, the control module on the recipient PC 
creates a pending event for return of the confirmation receipt file to the sending PC 
through the third party authenticator, designating the corresponding destination 
20 address. The confirmation receipt file is transferred to the third party authenticator 
along with the destination address of the sending PC that requested the confirmation. 
Still further, the third party authenticator, upon receipt of the confirmation receipt 
file, processes the file stamping a unique digital characterization of the file using 
commercially available file authentication application programs. The file 
25 authentication application programs are designed to create files for which any 
tampering or modification can be readily detected. Finally, the authenticated 
confirmation receipt file is transferred, after processing by the third party 
authenticator, to the destination address of the sending PC that requested 
confirmation. A copy of the authenticated confirmation receipt may also be sent to 
30 the recipient of the associated file transfer. 
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The logic for processing confirmation receipt requests is now described with 
reference to Fig. 5. Initially, at step 500 it is determined whether a receipt has been 
requested. If no receipt has been requested, at step 502 the logic returns to Fig. 4. 
Otherwise, at step 504 a file list is created. Preferably, the file list includes file 
5 attributes of the transferred files such as the files sizes, and the dates and times the 
file were created. Next, at step 506 a text file is created. The text file preferably 
includes the sending PC's identification, the receiving PC's identification, and the 
date and time the file packet was received. Then, at step 508 a confirmation receipt 
file is created. The confirmation receipt file is a combination of the file list and the 
10 text file. Subs'equently, at step 510 an immediate send event is created for the 
confirmation file. 

At step 5 12 it is determined whether direct return has been requested. If direct 
return has been requested, at step 514 a pending event is created with the PC that 
requested the direct return as the destination address. If direct return has not been 
1 5 requested, third party authentication has been requested. Thus, at step 516a pending 
event is created with an independent authenticator designated as the destination 
address. After completing either step 514 or step 516, the logic returns to Fig. 4 at 
step 518. 

Exemplary logic which executes at the third party authenticating machine is 
20 now described with reference to Fig. 14. Initially at step 1400 a socket is created for 
listening. In a preferred embodiment, the socket is at port 789. Then, at step 1402 
the third party authenticator listens on the listening port. When data is received, at 
step 1404 it is determined whether a request is being sent. If a request is not being 
sent, the logic returns to step 1402 and repeats. If a request is being sent, at step 1406 
25 a random data socket is created and assigned to a port, the number of which is sent 
to the requesting PC. Subsequently, at step 1408 the confirmation receipt file is 
received on the assigned port, and at step 1410, the file is authenticated. Next, at step 
1412 an immediate send event for the authenticated confirmation receipt file is 
created, and at step 1414 the requestor is sent the destination address received with 
30 the request. Finally, at step 1416 it is determined whether other data sockets exist. 
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If other data sockets do exist, the logic returns to step 1408 and repeats. If no other 
data sockets exist, the logic returns to step 1402 and repeats. 
Event Log: See Figure 15 

All communication events are automatically logged by the computer program 
in an event log file, characterized by event properties such as date, time, file structure, 
and file name. The user can view and interact w^ith logged events listed in the event 
log file by using a control v^^indow such as that shown in Fig. 15. Received files can 
be opened for viewing directly from the Event Log window, provided the file formats 
of the received files have been associated with an appropriate application program 
available on the receiving PC. Opening the files can be accomplished by selecting 
an event 24 listed in the Event Log window using the pointing device, then initiating 
control commands using the PC's pointing device or keyboard which opens a control 
window such as that shown in Fig. 16. The control window shown in Figure 16 
displays the properties of the logged event. Listed files can be opened by selecting 
the file 25, then initiating control conmiands using the PC's pointing device or 
keyboard which opens the file using an associated application program available on 
the PC. If no application program has been associated with the format of the listed 
file, a message informing the user or prompting user action is displayed. The Cancel 
button 26 closes the event properties window. The View Receipt button 27 displays 
any retum receipt associated with a selected event. 

Selecting and Sending Files/Packets: See Figure 17. Figure 19> Figure 20. Figure 
21 & Figure 25 

The user at any interconnected PC of the present invention can initiate a send 
file event in a variety of ways. For example, by interacting with a control window 
such as the window shovm in Fig. 17, the user can utilize the PC*s pointing device to 
select files listed in a transmit window 28. Subsequently, by mvoking the drag & 
drop function of the windows operating system, the user can drop files on destination 
objects 30 in the destination -window. In response to dropping the file on the 
destination object 30, a file list created by the windows operating system is linked to 
the address of the destination object 30 and the file will be sent. Preferably, the file 
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structure resident at the transmitting PC is replicated at the receiving PC for each sent 
file. 

In a preferred embodiment, manual confirmation is required for each file 
selected to be sent to each PC destination. The manual confirmation requires user 

5 action in order to transfer each file. An automated screening of file transfer 
authorization may also be provided which only permits authorized transfers to occur. 
The automated screening may occur prior to transmission to each PC destination for 
each file to be transferred. 

The buttons at the bottom of the destination window may also be employed in 

10 a preferred embodiment. Button 34 opens other destination windows. Button 36 
minimizes the destination window. Button 32 opens the transmit window 28. 

Altematively, a packet or file can be selected via the windows displayed in 
Figs, 20 and 21, and the destination can be selected via the window shown in Fig. 19. 
According to the procedure employing the windows in Figs. 19-21, the user selects 

15 a file or packet and creates a send event which can be scheduled either as an 
immediate transfer or a delayed transfer. 

In Fig. 20, a Drives drop down list 60 enables selecting a disk drive that stores 
the files to be sent. When a drive is selected, the directory structure is displayed in 
a display field 62 showing directories, subdirectories, and files. After the user selects 

20 a file, the selected file is displayed in a display field 64, along with the corresponding 
file structure. Preferably, any selected files shown in the display field 64 will be 
compressed (all together if multiple files have been selected) into a file packet (also 
referred to simply as a packet) before being transmitted. 

Clicking on a Description box 66 results in a user prompt 68 which permits the 

25 user to name the file packet and add a text message that will be sent along with the 
selected files. In a preferred embodiment, text identifying the user's name, 
organization, and address are automatically inserted. A text message may also be 
inserted into the dialog window by the user. Still fiirther, the inserted text is then 
linked, by a control module, to the list of files to be compressed by the compression 

30 subroutine into a packet for transmission by. a control module to a linked PC 
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destination address. The text information about the sender and text messages 
contained in received packets are displayed in the event log window when associated 
received files are selected by the user. 

In a preferred embodiment, one or more files may be selected from one or 
5 more directories in the file structure for compression, by a compression control 
module, into a packet for transmission to a destination PC address. The text message 
embedded with the files to be transmitted prior to compression at the sending 
computer is readily visible after decompression at the receiving computer. However, 
when encryption is enabled, text messages can be embedded with the files to be 
10 transmitted prior to encryption at the sending PC and made readily visible at the 
receiving PC after decryption. Altematively, the text messages can be embedded 
with the files to be transmitted after file encryption at the sendmg PC. Consequently, 
the text messages are readily visible prior to file decryption at the receiving PC. The 
text messages are saved in a text file that the receiving computer recognizes and 
15 consequently displays upon receipt. 

If the Description box 66 is not checked, no user prompt 68 is displayed, and 
the packet is created with a standard message and a random number as a name. The 
user prompt 68 may also be displayed when a Compress button 65 is selected. 
Clicking an OK button 69 initiates a compression fimction by calling the zip 
20 compression fimction in the compress.dll that creates the file packet. The user 
prompt 68 is then closed and the Compress button 65 is replaced by a Next button 
that enables the user to switch to the select destination window (Fig. 19). 

If the user wishes to send a previously created file packet, a send existing 
packets window (Fig. 21) can be reached via the Packet menu 50 in Fig. 19, or in any 
25 other screen where the Packet menu appears. In Fig. 21, selecting a packet 70 then 
clicking on the Next button 71 switches the user to the select destination window 
(Fig. 19), where the destination for the selected packet can be designated. Double 
clicking on a packet 70 results in a display 72 showing the contents 73 of the packet 
and any associated message 74. Clicking the Cancel button 75 closes the display 72. 
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The Clear Entry button 76 deletes any selected packet 70. The Clear List button 77 
deletes all packets 70 in the list of displayed packets. 

The select destination window for selecting a destination to send the file to is 
now described with reference to Fig. 19. The Packet menu 50 enables initiating a file 

5 transfer, index request^ file request, or log display. A Control menu 5 1 offers options 
for establishing a link to an active Intemet/intranet/extranet connection and/or 
initializing a modem. An Index menu 52 permits accessing the index build/edit 
function, and a volume manager. The volume manager enables naming and deleting 
volumes, which are logical divisions within an index. A Setup menu 53 enables 

10 modifying the computer program setup in terms of directories, modem parameters, 
user information, encryption program interface, and also enables access to destination 
books which create lists of destinations. A Help menu 54 accesses usage instructions. 

A Change button 55 accesses destination books. A Browse button 56 
facilitates finding previously created file packets. The packets are displayed in a 

15 dialog box that appears when the Browse button 56 is selected. A Previous button 
57 retums the display to the previous display screen. A drop down list 58 displays 
candidate destinations from which the user may select the destination to which files 
will be sent. A Send button 59 initiates a transfer of selected files to the selected 
destination. 

20 Another procedure for sending a selected file to a selected destination is now 

described. While the user is working within an application program, the user may 
save the working file to a directory associated with a particular destination, i.e., 
destination linked directory (DLD). Files may be saved to the directory utilizing a 
Save As option, or may be automatically written into one or more DLDs as automatic 

25 output from a companion application program. Subsequently, all files within the 
directory (i.e., DLD) to which the files were saved are sent to the destination 
associated with the directory. In a preferred embodiment, the transfer occurs 
immediately after the file is saved. However, the transport interval may be set for 
immediate or delayed time periods. Thus, by saving files to the directory associated 

30 with the particular destination or group of destinations, the files will be sent to that 
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destination or group of destinations without additional user action. Multiple 
directories, each associated with a particular destination, may also be employed 
allowing the user to select the destination to which the file will be sent. These 
directories may be created at the time a destination is defined in the destination book 
5 by the user. DLDs enable integration of the present invention with other application 
programs at the operating system level without the use of an application programming 
interface (API). 

Whenever a file is written into a DLD, the file is sent to the destination that 
has been associated with the DLD, then deleted from the DLD. A user option allows 

10 the file to be written into the DLD and then saved into an archive file other than the 
DLD before the file is deleted. The present invention allows the user to create 
multiple directories associated with destinations and store them in the destination 
book. Whenever a user places a file in one of those directories, it is sent to the 
associated destination. This enables seamless interfaces between large groups of 

15 computers over wide area networks. Computers that generate large numbers of files 
(such as invoices) requiring distribution to a large number of recipients can be 
automatically and directly linked to the destination computer using DLD structures. 

The receiving computer that receives the transfer from the DLD must be 
actively connected to a communications pathway accessible to the sending computer. 

20 If the receiving computer is not actively connected, the sending computer can 
repeatedly attempt to transfer the file. In a preferred embodiment, the attempts stop 
after a user selected time-out period elapses. Altemately, the sending computer may 
wait until it is determined that the receiving computer has become connected. The 
receiving computer receives the files in a directory designated to receive files by the 

25 receiving computer's user. A discrete cormection is established for each file transfer 
initiated with each receiving PC, as described above. 

Referring to Fig. 25, an exemplary process for scheduling a file send event is 
now described. Initially at step 2500 a file/packet and destination are selected 
according to one of the procedures described above. Next, at step 2502 it is 

30 determined whether the user is authorized to send the selected file to the selected 
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destination. If authorization is not confirmed, at step 2504 the user is asked to 
confirm that the selected destination is the destination to which the user actually 
intends to send the file. If confirmation is not received, at step 2506 the file transfer 
is aborted. Otherwise, and also when authorization occurs at step 2502, at step 2508 
5 it is determined whether a previously established packet is being sent. If the packet 
has not yet been established, at steps 25 1 0, 25 1 2, and 25 1 4 the packet is compressed, 
link identification information and authentication codes are created, and the packet 
is encrypted. 

After the compression, and also when it is determined that the packet already 
10 exists, at step 2516 it is determined whether the file transmission is to occur now or 
later. If the transfer is to occur later, at step 2518a scheduler is opened, and at step 
2520 the user inputs the date and the time when the file transfer should occur. 
Subsequently, and also when the file is to be sent immediately, at step 2522 a send 
event is created. 

15 Finally, at step 2524 the send event is scheduled as a pending event. in the 

main control module. At this point, the computer program treats the file like any 
other pending event set up by the user. The program is constantly in the process of 
monitoring the queues and sending any pending events found with a time that is 
earlier than or equal to the current time. 

20 Setting up a destination: Figure 17. Figure 18 & Figure 19 

In preferred embodiments, a user function is provided to invoke a destination 
window, with which one or more destination files may be created. The destination 
window may be used to select a destination file and to add, delete or modify 
destinations in a destination file. A destination address may be selected fi-om a 

25 destination window by the user for use by a control module to transmit a packet. In 
preferred embodiments, a user function is provided to invoke a dialog window fi-om 
which the user may set a specific date and time when a control module will initiate 
transmission of a specific packet. 

In preferred embodiments, a user function is provided to add destination PC 

30 addresses as nick name objects in a destination window. The nick name objects 
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added to the destination window are linked to the specific destination addresses 
contained in the destination file. Preferably the number of possible destination 
addresses allowed as destination targets for a sending PC is controlled by setting a 
preset non-user-adjustable Hmit (a locking limit) in a control module for the number 
of entries allowed in the destination file. Also, the number of destination files 
allowed for a sending PC is controlled by setting a locking limit in a control module 
for the number of destination files that can be created or viewed. The locking limit 
may be preset in the software by the software developer/manufacturer during 
installation disk production before the software is shipped to a user for installation 
onto the computer. 

In preferred embodiments, a user fimction is provided to invoke a dialog 
window that enables modification of a destination address from a destination 
window. Moreover, a user fimction is provided to invoke a dialog window from 
which the user may create or select for display additional destination windows. In 
preferred embodiments, a user fimction is provided to launch a file structure display 
window from a destination window. 

According to a preferred embodiment, a discrete destination and associated 
address can be defmed or modified, and saved in a destination file by user interaction 
with a control window such as that shown in Fig. 1 8. Once defiuied and saved, a 
destination file can be selected and displayed in a destination window such as that 
shown in Fig. 19, and can be linked to a destination object in a destination window 
such as that shown in Fig. 17. A destination file can also be linked to a directory to 
create a DLD. 

A procedure is now described for adding or modifying a destination according 
to a preferred embodiment. The Setup menu 53 is selected to access the window 
shown in Fig. 18. Then, the user selects the New button 40, or selects a destination 
and selects the Edit button 42, Clicking on button 40 results in a dialog box display 
that enables entry of destination information comprising name, address, address type 
(e.g., PSTN number, IP address number), or creation of groups of destinations. A 
group of destinations allows a file transfer to be made to all destinations within the 
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group with a single user action. Button 42 is used to edit parameters of an existing 
destination. Clicking on the Edit button 42 results in a dialog box display that 
enables modification of destination information. 

For modem destinations, the user enters the telephone number of the modem 

5 destination. For hitemet addresses, the user enters the IP address of the destination. 
After inputting the information, the user selects a Finished button- 48 and the 
destination is added to the destination book. The Finished button 48 closes the 
destination book window. A box (not shown) may also be checked causing a 
destination linked directory to be setup for the destination. A default name for the 

1 0 DLD may be set to the destination's nickname or the full destination name. 

The present invention preferably stores all information about a destination in 
the destination book that is portable from one computer to another and easily shared 
among users. Destination books provide an easy way to send a file to a group of 
users. The user simply selects the group as the destination of the data file containing 

15 the destination book information. The present ii^vention then sends the file to all 
users in that group. 

A Remove button 44 removes listed destinations. An Add to Group button 46 
creates groups of destinations tiiat allow a file transfer to be initiated to multiple 
destinations with a single user action. 

20 In order to add a destination to the destination bar, such as that shown in Fig. 

17, a user may right click on a destination object 30 if the destination object 30 is 
empty (i.e., not associated with a destination). In response to the right click, a drop 
down box appears that lists destinations defmed according to the procedure described 
above. ,The user may then select a destination from the destination list and change 

25 a nickname associated with the destination, if desired. Consequently, the nickname 
will appear in the destination bar if the destination object 30 is not empty (i.e., not 
previously associated with a destination). The modifications to destination 
parameters are then saved in a destination file. 
Creating an Tndex; See Figure 6 & Figure 22 
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In a preferred embodiment, the user may create an index of files stored on the 
PC's file storage device that can be requested by other PCs across a cormected 
communications pathway. The index is created by selecting files from the file list 
window. The file names and file structure are then added to an index file in a display 
5 window by the control module. 

In preferred embodiments, a user function is provided to invoke an index 
request sequence in which a user may select a PC destination to which an index 
request will be sent. Upon selecting a PC destination for an index request, a control 
module initiates transmission of the index request, the identification, and the address 
10 of the requesting PC. The PC destination that receives the index request checks the 
requesting PC*s identification for authorization, and then returns the index linked to 
the requesting PC (assuming it is authorized) to the address received from the 
requesting PC. Upon receipt of the index, a control module stores the index linked 
to the associated destination address in an index file on the receiving PC's file storage 
15 device. In a preferred embodiment, indexes may be requested from multiple PC 
destuiation addresses. 

In a preferred embodiment, the user may create one or more indexes of files 
stored on the PC's storage device. Each index created may then be linked to a 
specific destmation address (i.e., a private index). Still further, an index linked to a 
20 specific destination address, which may include identifiers such as user name, 
identity or site code, serial number, etc., is the only index that will be transmitted to 
a requesting destination PC having that specific destination address. The private 
index capability enables users to retrieve files from another computer without 
allowing the user to login or control the computer that has the desired files. Thus, the 
25 private index reduces security risks. 

Moreover, an index linked to no specific destination address (i.e., public 
index) will be transmitted to any destination address. In other words, the public index 
is accessible by all users. In other preferred embodiments, the index is created by 
selecting, from the destination dialog window, the destination address desired to be 
30 linked, and then selecting files from a file list window. The files names and file 
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structure are then added by the control module to the destination linked index file and 
an index display window. 

In other preferred embodiments, a user may encrypt the packet containing the 
files in the file list to be passed to the pending event log file. The control module 
calls an encryption subroutine which encrypts the packet containing the listed files. 
Using commercially available encryption software having "public key/private key" 
technology, a public key code may be used to encrypt files. The public key code is 
linked to the destination address to which the files are to be sent. The public key 
code for each destination address is generated fi*om a private key code, both of which 
are generated and linked to the destination address during system setup at each PC 
destination. The public key code, but not the private key code, created for each PC 
destination, can be received by each system PC automatically upon request from 
another destination PC. The public key code linked to a destination is used for 
encryption of files to be transmitted to that destination. Only the private key for a 
specific destination can be used to decrypt files encrypted with the public key for that 
destination. Files received at a PC destination that were encrypted using the public 
key for that destination are decrypted automatically using the private key for the 
receiving PC. 

In still other preferred embodiments, encryption programs may be invoked by 
the user to encrypt files, manually selecting the appropriate public key, prior to 
selection for transmission to a destination PC. Decryption programs may also be 
invoked by the user to decrypt files with a private key code manually selected afi:er 
receipt of the files. Automatic encryption and decryption without public key 
exchange may be used. Such encryption technology does not use public key/private 
key technology, but rather a "one time pad" encryption key. The present invention 
provides a user option that allows a user to select a security product that the user 
wishes to utilize. It also provides the option to use a TriStrata Security Architecture 
that provides centralized security policy management eliminating the requirement for 
public key exchange, and provides very fast encryption and decryption. TriStrata 
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Security Architecture is a developer's kit publicly available from TriStrata Security, 
Inc. of Redwood Shores, California. 

In a preferred embodiment, a user function is provided to invoke a file request 
sequence that allows the user to request files from a selected index in order to request 
5 files from the associated destination PC address. Still further, when one or more files 
listed in the index are selected by the user, a control module initiates tr^smission of 
the request for the files along with the identification and address of the requesting 
PC. When a PC destination receives a request for one or more files in an index, a 
control module calls a compression subroutine which copies and compresses the files 
10 contained in the received request, creates a packet file and passes the packet to the 
pending events file. In another preferred embodiment, if automatic encryption is 
invoked, packets contanimg the compressed files are encrypted using a public key 
Unked to the requesting destination or a one time key linked to the exchange 
transaction. A preferred compression algorithm (compress.dll) is publicly available 
15 from Infozip Group. Other compression algorithms are conmiercially available and 
may be used in preferred embodiments. 

A control module initiates a connection with the destination PC using the 
destination address received with the file request. Still fiirther, a control module 
identifies the sending PC by its address, then transmits the packet containing the 
20 compressed requested files to the linked address across the connected pathway. 
When the transmission of the packet is complete, the control module indicates a 
successful transfer in the event log window by date, time and content. In preferred 
embodiments, a control module responds to inbound file transmissions, captures, 
decompresses, and writes transmitted files to the computer file storage device using 
25 the received associated file structure, and creates a received file list that is linked to 
the stored files and displayed in the event log window showing date, time, and 
content. 

Accordmg to a preferred embodiment, the user of any interconnected PC of 
the present invention can create an index of files from which another designated PC 
30 can request files. Moreover, multiple indexes can be created, each authorizing a 
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request from different interconnected PCs and comprising different file lists. The 
multiple indexes are established by associating each index with a specific destination, 
and then selecting files to be listed in the index. Thus, different files can be in each 
index. In a preferred embodiment, a volume name (disk label) is utilized for an index 
5 authorized for transmission to any requesting PC. Alternatively, the destination 
name, destination address, intemal serial numbers, or authentication codes can be 
utilized to restrict transmission of each index created to a specific destination PC. 
The index is created by user interaction with control windows such as those shown 
in Figure 22. 

10 In Fig. 22, a Drive button 80 displays a drop down box that enables selecting 

a drive from which the files to be indexed can be selected. Checking box 81 allows 
building an index that contains the content of a specific directory tree. Checking box 
82 enables rebuilding a specific index. Checking box 83 enables building an index 
contaming files before or after a specific date arid time. Button 84 varies the 

15 reference time for the index from the current time displayed. Button 85 modifies the 
reference date for the index from the current date displayed. Box 86 enables building 
an index containing only a specific file extension (e.g., "doc"). Box 87 enables 
building an index containing all files on a logical drive. Button 88 returns to the 
previous computer program screen. Button 89 initiates the build index process using 

20 the parameters selected by designation of boxes 81 through 87. 

The index created comprises a database tree including linked Usts of operating 
system file block structures. These structures are utilized by operating systems to 
store information about the file, and its state. Each node of the tree contains pointers 
to its siblings, and to its children and parents. In this way, the index retains the 

25 directory structure information. When a file is added to the index, each level goes 
into the tree. 

An example for adding a file to the index is now described. Consider the file 
report,txt with its associated drive and directory structure being 
E:\sky\cIouds\bird\report.txt. When adding the file to the index, "E:\" is not utilized, 
30 because only the structure of the directory, and not of the drive is important. 
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Therefore, the database is searched for "sky", starting at the root of the database and 
moving across the siblings. If "sky" is not found, it is added to the list, preferably 
keeping the list in alphabetical order. Subsequently, the search for "clouds" begins 
with the first child of the "sky" node, moving across the siblings. If "clouds" is not 

5 found, it is added to the list, preferably keepmg the list in alphabetical order. The 
process repeats with the first child of "clouds" and the search for "bird" commences. 
The same process executes with "report.txt." The process is highly recursive because 
the process is repeated for each level of indenture of the directory tree until the file 
name is reached. Filename nodes in the index have no children, but may of course 

10 have siblings. 

The process for creating each index using a control window, such as that 
shown in Fig. 22, is now described with reference to Fig. 6, Initially at step 600 the 
user indicates that an index is going to be created. Then, at step 604 a filename list 
is generated based upon the user selected options. For example, if From Directory 

15 is checked, the user can select specific files names to be included in the list. If other 
options are checked, the list is generated with the file structure based on the options 
selected. 

At step 606 the first name in the list is determined. Then, at steps 608-622 the 
index structure is recursively buih until the name is included in the list. When it is 
20 determined at step 610 that the file name has been added, at step 624 it is determined 
whether the list has been completely built. If the list is finished, at step 626 the logic 
terminates. Otherwise, at step 628 the next item in the list is determined and the 
process repeats at step 608. 

Requesting a File or an Index: See Figure 7. Figure 8. Figu re 19 & Figure 23 
25 According to a preferred embodiment, the user at any interconnected PC of the 

present invention may initiate a file or index request event by interacting with control 
windows, such as those shown in Figs. 19 and 23. A file request event is initiated by 
using the PC's pointing device to select an index fi-om a displayed list in a control 
window, such as that shown in Fig. 23, then selecting files listed in the index, and 
30 invoking a request event. The user can initiate an index request event by invoking 
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a request control from the Index menu 52 in a control window, such as that shown in 
Figure 19, and then selecting the destination from which the index is to be requested. 

The computer program links an index request to the destination address 
associated with the selected destination, and then schedules a send event in the 
5 pending event file. The identification and address of the requesting PC is sent as part 
of the request. In the present invention, the computer program in each PC receiving 
an index request will return only an index specifically created and authorized for the 
requesting PC, unless the receiving PC has an index created and authorized for 
general distribution to interconnected PCs. Further, a file request can only be 
10 initiated from an interconnected PC after downloading one or more indexes from 
other interconnected PCs. 

Referring to Fig. 7, exemplary logic for requesting a file or an index is now 
described. Initially, at step 700 the user selects the files desired from a remote index 
previously downloaded or selects an address from which to download an index. 
15 Then, at step 702 it is determined whether the request is for a file or an index. If an 
index has been requested, at step 704 an index text file is created. Alternatively, if 
a file is requested, at step 706 a file list text file is created. Then, after steps 704 and 
706, the newly created text file is scheduled as a pending event that will be sent by 
the send file module of Fig. 3. Finally, at step 710 the logic terminates execution. 
20 Because the program is always waiting for files, the program is waiting for a request 
return. 

Referring to Fig. 8, exemplary logic that executes on the receiving computer 
is now described. Initially at step 800 the receiving computer receives a text file 
containing a request. Then, at step 802 it is determined whether the request is for an 

25 index. If the request is not for an index, the request is parsed at step 804, and the files 
are located. Subsequently, at step 806 the requested files are compressed, and at step 
808 a send event linked to the requesting PC is created. After the event is created, 
at step 810 encryption occurs if encryption has been enabled, and at step 812 the files 
are sent to the requesting PC in accordance with the procedure described with respect 

30 to Fig. 3. 
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If at step 802 it is determined that an index has been requested, at step 8 16 it 
is determined if the requested index is authorized for transmission to the requesting 
PC. If the index is authorized, at step 818 the index is compressed and the logic 
proceeds to step 808 for transmission as previously described. If the index is not 
authorized, at step 820 a message is created which informs the requesting PC of the 
denial. Subsequently, at step 822 the message is compressed and sent to the 
requesting PC at steps 808-8 12. 

In Fig. 23, a button 90 displays a drop down box that enables selection of an 
index received from any PC listed in the destination book. The files contained in the 
selected index are displayed in a display field 92, along with the associated file 
structure. Files are selected for request by clicking on the listed files with the PC's 
pointing device. Selected files are displayed in a display field 94. Clicking on a 
Request button 96 initiates the request of the selected files from the PC fi-orii which 
the selected index was received. A Delete button 98 deletes an index, usually when 
a new, more current index has been requested to replace the index being deleted. 

The present invention can also include an auto polling feature that provides 
the ability to poll groups of destinations all at once and simultaneously receive all 
files transferred as a result of the poll Auto polling is enabled when the user places 
files in a directory corresponding to a remote destination. The remote destination can 
subsequently poll that directory causing those files to be transferred to the remote PC. 
Auto polling is similar to the index fiinction previously described, except that with 
auto polling the remote PC does not request specific files, all files in the directory are 
sent to the remote machine upon polling. Due to the ability to have multiple, 
simultaneous connections, a computer polls all remote machines in parallel. Parallel 
polling provides the advantage that many files can be received fi-om many different 
locations quickly. The return receipt feature described below can be utilized with the 
parallel polling feature to provide additional benefits. 

In a preferred embodiment, if an improper computer polls a directory to trigger 
a transfer, the transfer occurs. However, the transfer will not be to the improper user. 
The transfer will go to the computer associated with the directory being polled. 
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Automated Update 

According to another embodiment, an automated update feature may be 
provided. The automatic update feature allows the user to electronically receive new 
software version releases and automatically install the software updates. Options are 
5 provided for automatically or manually updating , upon receipt of electronic 
transmission of a new software version release. 

When an update is transmitted to recipients, if automatic update has been 
selected during setup at a recipient PC, the previous version installed at the recipient 
PC is automatically replaced by the new release version files. Automatic update is 
1 0 accompUshed by transmitting, along with the new release version computer program, 
(1) an update identifier in the file list header for the packet that differentiates the 
update package from other types of received files; (2) an authentication code unique 
to the software manufacturer; and (3) an install program and a set of control 
commands that are executed by the currently installed version of the software. 
15 Depending upon the specific requirements of the new release, the control commands 
may terminate operation of the current version, copy new files, and/or install 
modifications required for operation of the new version. The operation of the new 
version is initiated by either the control commands or the install program for the new 
version, depending upon the extent of the upgrade. The install program will 
20 preferably unlink DLLs, copy new DLLs, copy new executable files and run the new 
program version. "Ultimately, the install program terminates itself 

If manual update has been selected during setup at the recipient PC, the 
electronically received software updates are saved on the recipient PC's storage 
device with the same file stmcture as the sending PC's file structure. The user at the 
25 receiving PC can manually initiate the install routine for the new release version at 
a later date when installation of the update is desired. 
Credits: See Figure 9. Figure 11, Figure 12. Figure 13 & Figure 24 

Another embodiment of the transmit window and destination bar is shown in 
Fig. 24. A Drives button 100 enables selecting the drive where the files desired to 
30 be sent are stored. When a drive is selected, the directory stmcture is displayed in a 
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display field 101, showing directories, subdirectories and files. When files are 
selected using the pointing device, the selected files are displayed in a display field 
102, along with the corresponding file structure. Clicking on an Encrypt button 103 
calls an encryption application program for encrypting the files with the public key 
5 for the destination where the files are to be sent. An Add to Index button 1 04 enables 
adding the selected files to a specific index. Clicking on a Next button switches to 
the select destination window (Fig. 19). 

If the user left clicks a destination object 30, the selected files are sent to the 
associated destination address, after being prompted for confirmation of the 
10 destination selected and whether a delivery confirmation receipt is requested. In a 
preferred embodiment, the viewer may select confmnation receipt as either direct or 
through a third party authenticator. Button 108 initiates a request for transmit credits, 
by displaying a dialog box that prompts the user for the number of credits being 
requested and user account information. Display bar 109 (a.k.a-, fiiel gauge) 
15 indicates the number of transmit credits remaining. 

Accordmg to another preferred embodiment of the present invention, a credit 
system may be employed. The credit system controls the number of transmissions a 
specific sendmg PC may send. The credit system operates by setting a value of an 
adjustable locking limit, then decreasing the value of the locking limit by a 
20 predetermined amount after successfully completing each file transmission. The 
locking limit value may be decreased until the value reaches zero, in which case no 
ftirther transmissions are permitted until the locking limit has been reset to a value 
other than zero. In other words, a certain number of credits may be provided at the 
specific sending PC and the number of credits decreases after each successfiil file 
25 transfer until no credits remain. The file transfer fimction is suspended at the specific 
PC once the value of the incrementally modified lockmg limit at that PC reaches a 
null value. In other words, no transfers are allowed after the credit balance reaches 
zero. Therefore, before any transmission occurs, the send file module, shown in Fig. 
3, checks the credit balance to determine if the sending PC has enough credits for the 
30 requested transmission. If an insufficient balance is found, a message is sent to the 



wo 99/26121 PCT/US98/24373 

Page -67- 

user indicating the balance is insufficient, along with instructions as to how to obtain 
additional credits. A message may also be displayed indicating when the number of 
credits drops below a certain predefined level advising the user to obtain additional 
credits. According to another embodiment, a transaction count increases after each 
5 successfol file transfer, and no fiirther transfers are permitted when a predetermined 
maximum number of transactions is reached. 

According to another embodiment of the present invention, the file transfer 
fimction is restored by resetting the locking limit to a value other than the null value, 
i.e., obtaining additional credits. The user obtains additional credits by invoking a 
10 user authorization request. To initiate a request for credits, the user clicks on the 
request button 108 (shown in Fig. 24.), and is subsequently prompted for appropriate 
account information. If the information has been entered previously, an opportunity 
is provided to edit the information before sending it. The number of credits being 
requested is also collected, either automatically (e.g., a default amount) or through 
15 user prompts. Exemplary accounting information that may be collected includes a 
credit card number, or an account number indicating the requestor, e.g., a business 
account. Thus, to obtain credits, the user must either have set up an account before 
requesting credits and provide an account number with each credit request, or 
alternatively, provide credit card information. Preferably the accounting information 
20 and the number of credits requested along with the sending PC's identity 
autiientication and IP address or telephone number are transmitted to an independent 
authorizing computer system 16 (credit processor) (Fig. 1) using the previously 
described file transfer method, through a connected communications pathway. The 
request is sent to a specific credit processor 16 at a specific, fixed IP address 
25 previously provided to the sending computer. According to another embodiment, the 
user's credit can be established by inserting an authentication device into the PC's 
floppy drive or a device reader. Consequently, the PC reads the information firom the 
authentication device. 

After the authorizing computer system 16 receives the authorization request, 
30 the connection between the requesting computer and the authorizing computer system 
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16 terminates and the authorizing computer system 16 begins processing. After 
completing processing, the authorizing computer system 16 contacts the requesting 
computer via the standard listening port and indicates denial or the number of credits 
approved without establishing an additional connection. Only a single connection is 
5 utilized for this message for security reasons. Upon validating the accounting 
information, the credit processor returns an authorization and transmission control 
code to the requesting PC corresponding to the number of file transmissions 
authorized. Preferably credit processors do not store and forward files, nor process 
file transmissions. 

1 0 Referring to Fig. 9, exemplary logic for requesting credits is now described. 

At step 900 the user selects the number of credits desired; in a preferred embodiment 
25, 50, 75, or 100 credits. Then, at step 902 the account information is displayed (if 
previously provided) and edited, or collected (if not previously provided) via 
prompts. Finally, at step 904 the request is forwarded to the main control module for 

15 transmission to the credit processor 16. 

At least one authorizing computer system 16 should be provided for the 
purpose of authorizing and issuing credits, processing the accoimting information 
received in the authorization request and, upon validation of the accounting 
information, informing the requesting PC of the successful validation of the 

20 accounting information. If the validation of accounting information is unsuccessfiil, 
a message indicating the denial may be returned to the requesting PC causing a 
message to be displayed indicating the unsuccessful credit request. Preferably, the 
credit processor 16 is a special computer set up exclusively to process credit requests 
by validating accounting information. No document files are transferred through the 

25 credit processor 16, and there is no provision nor requirement for login. The credit 
processor 16 is setup at a specific IP address and processes the accounting 
information received in the authorization request for credits. 

Operation of the credit processor 16 is now described with respect to Fig. 10. 
At step 1000 a socket is created, at port 789 in a preferred embodiment. At step 1002 

30 the credit processor "listens" for a credit request on port 789. At step 1004 upon 
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receipt of a request, it is determined whether received data represents a credit request. 
If it is determined that the received data is not a credit request, the logic returns to 
step 1002, Otherwise, if a credit request is received, at step 1006 a random data 
socket is created and a port is assigned for receiving the authorization request. 
5 Subsequently, at step 1008 the authorization request is received at the assigned port. 
At step 1010 the accounting information (e.g., account number, credit card number, 
and expiration date) is extracted from the received data. At step 1012 the account is 
verified, e.g., the account is checked for validity or the credit card charge 
authorization process executes. If the account is verified, at step 1016 the 
10 authorization for credits requested is returned to the requesting PC on port 789. If, 
at step 1018 it is determined that additional data sockets exist, the process returns to 
step 1008 to concurrently process other requests received, as described above. If no 
other data sockets exist, the process returns to step 1002 and the process repeats. If 
at step 1012 the account is not verified, at step 1014 an unauthorized account 
1 5 message for requests not approved (e.g., due to no account number, failed credit card 
authorization, etc.) is returned to the requesting PC. 

The authorizing computer system 16 performs standard credit card processing 
to determine if the cost for the amount of credits requested is available on the 
submitted credit card. If an account number is submitted instead of a credit card 
20 number, the account number is forwarded to a standard accounting system for 
verifying whether the account is valid and whether the requested amount is available 
from that account. If the accounting information is validated, a confirmation message 
is sent back to the requesting PC along with the number of credits authorized. Upon 
receipt of the confirmation, the requesting PC increases the credits by the number of 
25 credits authorized. Altematively, the authorizing computer system 16 can approve 
fewer credits than requested. 

Upon receipt of credit authorization, the main control module calls the add 
credits routine, shown in Fig. 11, to add the new authorized credits to the current 
remaining credits. Referring to Fig. 11, at step 1100 the requesting PC reads the 
30 number of received credits returned by the credit processor. Then, at step 1 102 the 
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requesting PC decodes the current credit balance remaining. Any known form of 
decoding/encoding may be used in order to prevent users from tampering with the 
number of credits contained on their PC. Alternatively, an external device such as 
a "Smart Card" can be used to store the received credits authorization. At step 1 104 

5 the new credits authorized are added to the remaining credit balance. Then, at step 
1 106 the new credit value is encoded. Finally, at step 1 108 the new credit balance 
is displayed, in a preferred embodiment, on the credit bar 109 shown in Fig. 24. 

When a file is transferred by a PC, the main control module calls the remove 
credits routine, shown in Fig. 12, to modify the remaining credits by one or more 

1 0 credits. According to a preferred embodiment, a different number of credits may be 
deducted for file transfers of different sizes. For example, file transfers of less than 
one megabyte may only require one credit per transfer, whereas files greater than or 
equal to one megabyte may require two credits per transfer. 

Referring to Fig. 12, an exemplary process for removing credits for file 

15 transfers is now described. At step 1200 the number of credits required for the 
present transfer is determined. The number of credits required for each file size may 
be stored in a lookup table. Then, at step 1202 the current credit balance is decoded. 
At step 1204 the cost of the transaction is subtracted from the current credit balance. 
Finally, at step 1206 the modified credit balance is encoded, and at step 1208 the new 

20 credit balance is displayed. 

Accordmg to a preferred embodiment, a flat rate billing system is employed. 
For example, a business may pay a fixed amount for an unlimited number of transfers 
per month. In order to implement the flat rate billing system, a limit should be set for 
the total number of credits allowed on each PC at any given time. The number of 

25 credits should be limited in case a business subscribing to the flat rate service defaults 
on the monthly payment. The fixed maximum number of credits prevents the 
defaulting business from having an excess number of free credits on the business' PC 
after defaulting and thus receiving extra free transfers. Of course some credits may 
remain on the defaulting business' PC after defaulting; however, the maximum 

30 reduces the loss. 
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According to the flat rate system, the local machine limits the number of 
credits requested to keep the machine from exceeding the maximum. For example, 
if the maximum number of credits allowed is 100 credits, the user currently has 90 
credits, and the user requests 50 credits, the requesting PC prevents the request from 
5 transmitting. Altematively, the requesting PC may reduce the request to the number 
of credits allowed, in this example 10 credits. When the number of credits on a PC 
subscribing to the flat rate service depletes the credits on the PC, authorization merely 
determines whether the submitted account number is a valid account, and the number 
of credits requested will be the number of credits necessary to reach tihe limit. 
10 According to another preferred embodiment, the number of authorized file 

transmissions remaining at each PC is dynamically displayed. Thus, the number of 
credits currently available is displayed, and when the number of credits changes, e.g., 
due to a file transfer, the change is indicated on the user's display screen. One 
embodiment of the dynamic display is shown in Fig. 24 as a credit fuel gauge 109 
15 showing the number of credits currently available. The percentage of available 
credits relative to the maximum number of credits may also be displayed. Again, the 
number of credits displayed reflects any changes in the adjustable locking limit due 
to either purchasing additional credits or expending credits for transfers. 

Although Fig. 1 shows only a single credit processor 16 and independent 
20 certification processor 18, multiple credit processors and multiple independent 
certification processors may exist. If multiple credit processors and independent 
certification processors exist, each PC 10 preferably is informed of each address and 
selects the systems to contact randomly. In a preferred embodiment, each PC 10 
contains a difierent subset of the addresses, thereby distributing the network traffic. 
25 According to a preferred embodiment, even in the event of a transmission 

error, an error doctor enables files to be successfully sent. In order to achieve 
successful transmission, the control module operating at the sending personal 
computer partitions a group of files being transferred between personal computers 
into two discrete segments. Each discrete segment contains a portion of the files to 
30 be transferred. The partition occurs at the point where the transmission error 
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occurred, the first segment having been successfully transmitted, the second segment 
having failed transmission. 

The protocol used for transferring the files, e.g., TCP/IP, informs the sending 
PC of when the transfer was interrupted, i.e., when the connection was lost. After 

5 losing the connection, the sending PC establishes another connection and attempts to 
retransmit the entire group of files. However, the receiving PC immediately advises 
the sending PC that the last transfer was incomplete and informs the sending PC of 
the amount successfiiUy received. In a preferred embodiment, the receiving PC 
subtracts a buffer amount firom the amount actually received to compensate for any 

10 errors that may have occurred near the end of the interrupted transmission. The 
sending PC then calculates what portion of the group has not been sent, i.e., the 
second segment, and sends the second segment to the same receiving computer. 
Upon receipt, the receiving PC Overwrites an amount equal to the buffer at the end 
of the first segment and then combines the two discrete segments into a isingle packet 

15 of compressed files without loss of file content. In the event of additional 
interruptions, the process repeats until the entire file is successfiilly received or until 
the sending PC stops trying to send the group of files. Typically, the sending PC 
stops sending when the sending PC encounters excessive errors. 
Polling: See Figure 13 

20 The present invention is further directed to periodically polling connection 

status of destinations listed in the destination window. Connection status poUing 
involves requesting a retum of destination identifiers from all other recorded PCs in 
order to determine which PC destinations have active connections through which 
communication could be initiated. A visible indication may be provided which shows 

25 each active connection identified, thus notifying the user of which PC destinations 
are available for receiving a communication request. 

PolUng destinations for connection status is similar to pinging a remote site on 
a UNIX system. However, connection status polling is more sophisticated because 
it not only determines whether the site is active, but also determines that the identity 

30 of the site is indeed an intended recipient. The check for active IP connections 
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routine shown in Fig. 13 updates the status of connections for destinations listed in 
the destination window, as well as the number of credits remaining. 

Referring to Fig. 13, exemplary logic for executing the connection status 
polling process is now described. At step 1300 the logic determines the first 
5 destination in the destination bar. Then, at step 1302 an ID packet is sent to the 
address listed for the destination. At step 1304 the destination is marked as inactive 
and displayed accordmgly, e.g., dimmed. At step 1306 it is determined whether a 
response was received from the destination. If a response was received the program 
compares the response to the station name, or other authenticator code word, to make 

1 0 sure it matches what is on file. If they agree, the destination is marked active and file 
transfers can ensue. Thus, at step 1308 the destination is marked as active and 
displayed accordingly. Subsequently, at step 13 10 it is determined whether any other 
destinations have not been status polled. Similarly, if it is determined at step 1306 
that no response has been received or there is no match, the ID packet is simply 

15 thrown out and the destination is left inactive, and at step 1310 it is determined 
whether any other destinations have not been status polled. 

If any destinations have not been status polled, the next destination is 
determmed at step 1312, and the logic returns to step 1302 and repeats for that 
destination. If at step 1310 it is determined that all destinations have been status 

20 polled, at step 1312 the credit display is updated to show the number of credits 
remaining. Subsequently, the process terminates at step 1314. According to a 
preferred embodiment, the status polling process repeats periodically, for example 
every 20 seconds. When a remote site receives the ID packet, the receive file 
module, at step 422, sends back the receiving PC's station name and any other 

25 required authentication data as established during setup, which might include 
authentication codes for example. 

By way of example, a preferred embodiment of the present invention applied 
to an International Postal Service business model includes an unlimited numbers of 
service user computers having an active connection to a communications pathway, 

30 such as the Internet. Each computer runs the computer program of the present 
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invention enabling direct, substantially simultaneous, parallel, encrypted transfer of 
files between one computer and any number of other computers. Electronic receipts 
are automatically generated and automatically retumed to senders via a "trusted third 
party" certification processor, documenting files received at destination, computers. 
5, File transport between senders and recipients is immediate and direct. Service users 
pay for file transport through a reduction of credits in a credit account located locally 
at each user computer, and credits are restored electronically in proportion to 
payments at specified currency rates, with both charges and restoration being in 
accordance with a service provider policy. File transport security is assured through 
10 robust user authentication and file encryption. For example, computers operating 
as the following service processors: (1) one or more credit request processors, (2) 
one or more remm receipt certification processors, and/or (3) one or more 
encryption/decryption key issuer, user authenticator or security policy management 
processors (hereafter, security server) are present, operating and available through an 
15 active connection to the communications pathway. The physical location of these 
processing computers is important only for security policy and service user payment 
reasons, however, physical security of the processors is required. These issues are 
resolved in accordance with service provider policy. 

Eligibility for service use is gained through user identity authentication and 
20 registration in the security server. Access to service use is gained through installation 
and use of the computer program of the present invention. The computer program 
is obtained, for example, at the time of user registration. Service use consumes 
credits in the credit accomt stored in a user computer or on an external device (e.g., 
Smart Card obtamed at registration). Continued service use over time requires 
25 replenishment of credits through automatic requests for credits submitted to a credit 
processor. Payment for credits issued is in accordance with the billing or collection 
procedures and systems of the service providers. Credit authorization is retumed 
fi-om a credit processor to a user computer over the communications pathway (i.e., 
Internet), and the user credits are replenished. 
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Depending on the preference of the service provider, public key encryption or 
one-time-pad ericryption may be implemented. Files can be encrypted prior to 
transport using public keys for each destination obtained by each sender from the 
trusted third party security server. Alternatively, one-time-pads obtained 
5 automatically for each transaction between sender and recipient from the trusted third 
party security server can be used to encrypt files prior to transport. Encrypted files, 
along with authenticated user identity, and the "hash" ("electronic finger print") of the 
files being sent are transported directly between computers over the communications 
pathway (i.e., Intemet), without passing through the processors or security server. 

10 Received files can be decrypted using the recipients private key if public key 
encryption is implemented. Alternatively, received files can be automatically 
decrypted if one-time-pad encryption is implemented and the recipient's identity and 
decryption request to the security server comply with implemented security policy. 
Various security service policies, such as station to station encryption or person to 

15 person encryption can be effected. 

Completed file transport transactions are certified for the sender by a return 
receipt that is (1) generated by the computer program of the present invention 
installed on the file recipient's computer, (2) automatically transported over the 
Intemet to the certification processor, (3) "postmarked" by the trusted third party 

20 (certification processor), and (4) automatically transported from the certification 
processor to the file sender's computer. - The return receipt generated by the file 
recipient computer may contain a range of information such as date and time of file 
receipt, parties to the exchange by registered identity, an electronic finger print of the 
transported files (the hash), and characteristics of the files received. Upon 

25 certification of the retum receipt by the trusted third party certification processor, a 
range of additional information can be added such as the date and time of 
certification, the date and time of encryption and decryption (obtained from the 
security server), and the certification "postmark" of the ti^sted third party 
certification authority. 
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Other implementations of various business models according to the present 
invention are considered. Contemplated systems include those wherein (1) large 
arrays of computers or computing devices transport files primarily to one or relatively 
few destination computers; (2) one or relatively few computers transport files to large 

5 arrays of computers or computing devices; and (3) at least some of the system 
functions of the present invention are implemented, enabling direct, substantially 
simultaneous, parallel, encrypted transfer of files between one computer and any 
number of other computers, and enabling generation of electronic receipts 
automatically directly returned or certified through a trusted third party and then 

10 returned to senders, thus documenting files received at destination computers. 

Although the present specification describes components and functions 
implemented in the embodiments with reference to particular standards and protocols, 
the invention is not limited to such standards and protocols. For example TCP/IP and 
the Internet are referred to throughout this specification as representing examples of 

15 the state of the art. However, such standards are periodically superseded by faster 
and more efficient eqiiivalents having essentially the same fimctions. Accordingly, 
replacement standards and protocols having the same functions are considered 
equivalents. 

While the invention has been described with reference to several exemplary 
20 embodiments, it is understood that the words that have been used are words of 
description and illustration, rather than words of limitation. Changes may be made, 
within the purview of the appended claims, as presently stated and as amended, 
without departing firom the scope and spirit of the invention in its aspects. Although 
the invention has been described with reference to particular means, materials and 
25 embodiments, the invention is not intended to be limited to the particulars disclosed; 
rather, the invention extends to all functionally equivalent structures, methods and 
uses, such as are within the scope of the appended claims. 



30 



wo 99/26121 PCT/US98/24373 

Page -77- 

What is claimed is: 

1 . A file transfer device that transfers data with at least one remote device, 
the file transfer device comprising: 

at least one listening port which receives a control connection fi-om the at least 
5 one remote device; and 

at least one dynamically assigned data port for data transfer with the at least 
one remote device, each data port enabling a data transfer; 

wherein the control connection is utilized to transmit the address of the at least 
one dynamically assigned data port, 
10 wherein data is substantially simultaneously transferred with multiple remote 

devices via the dynamically assigned data ports. 

2. The file transfer device of claim 1, in which the control connection is 
• fiirther utilized to receive data transfer characteristics and authenticate the remote 
device by verifying the remote device's identifying information, the identifying 

1 5 information being transmitted fi-om the remote device. 

3. The file transfer device of claim 1, in which the control connection further 
comprises a selective acceptance system that compares the remote device's 
identifying information with a list of destination identities stored in a local device and 
prohibits data transfers fi-om remote devices not within the list of destination 

20 identities. 

4. The file transfer device of claim 1, in which each device substantially 
simultaneously sends and receives data to and fi-om multiple devices. 

5. The file transfer device of claim 1, further comprising a return receipt 
system that generates and sends a retum receipt fi-om a device that received the data 

25 transfer to a device that transferred the data after successfiil completion of the data 
transfer. 

6. The file transfer device of claim 5, further comprising a certifying system 
that communicates with an independent certifying processor that verifies return 
receipts, the independent certifying processor sending verification certification to a 

30 device that initiated the data transfer upon successful completion of the data transfer, 
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wherein the return receipt system generates and sends a return receipt from the 
device that received the data transfer to the independent certifying processor upon 
successful completion of the data transfer. 

7. The file transfer device of claim 1, in which each data port is represented 
5 by a socket data structure. 

8. The file transfer device of claim 7, in which each device stores the socket 
data structures in a linked list to manage the flow of data transfers, the linked list 
being traversed to enable substantially simultaneous data transfers. 

9. The file transfer device of claim 1 , further comprising a credit system that 
10 maintains and monitors data transfer credits and detects each data transfer in order 

to debit a credit account after a successful data transfer, the data transfer only being 
permitted when a device initiating the transfer has sufficient credits. 

10. The file transfer device of claim 9, in which a number of available credits 
for the device is dynamically displayed on each device. 

15 11. The file transfer device of claim 9, in which a transmitting device 

comprises a encrypting system that encrypts selected files prior to transmission, and 
a receiving device comprises a decrypting system that decrypts each encrypted file 
upon receipt, wherem the number of credits in the transmitting device is modified at 
least one additional credit upon each successful file transfer employing encryption. 

20 12. The file transfer device of claim 9, further comprising a credit request 

system that requests additional credits from an external credit processor in response 
to a request from a device for additional credits, the external credit processor 
validating account information of the requesting device and dispensing additional 
credits if the account information is validated. 

25 13. The file transfer device of claim 1, further comprising an index system 

that defines an index that can be requested by remote devices via the connection, the 
index comprising information indicating at least one file of which the remote 
computer can request a copy via a data transfer, and an associated destination, devices 
corresponding to the associated destination having exclusive access to the index. 
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14. The file transfer device of claim 13, further comprising an index request 
system that permits a requesting device to select the remote device where a request 
for an index will be sent, the request being sent to the selected remote device, the 
selected remote device returning the index to the requesting device, the requesting 

5 device storing the index in a storage device. 

15. The file transfer device of claim 14, wherein when each file listed in the 
index is selected by the requesting device, the requesting device requests that a copy 
of the selected file be transferred from the selected remote device, the selected remote 
device transferring each file in response to the request. 

'° The file transfer device of claim 1, in which each device further 

comprises: 

a variable number of destination linked directories, each destination linked 
directory associated wilh another device, each destination linked directory comprising 
a file storage area on the device; and 
15 in which the file transfer device further comprises a destination linked 

directory management system that detects storing of at least one data file in the 
destination Imked directory and initiates a transfer of the detected data file to the 
associated device in response to the detection. 

17. The file transfer device of claim 1, further comprising: 

20 an active connection monitoring system that periodically determines whether 

each remote device in a list of at least one remote devices is currently actively 
connected to a communications pathway accessible to a local device; 

a vaHdating system that validates each remote device in the list of at least one 
remote devices that is currently actively connected to the communications pathway 

25 accessible to the local device; and 

amonitoring system that defers a file transfer to a time when a selected remote 
device becomes actively connected to the communications pathway accessible to the 
local device if the selected remote device is not currently actively connected to the 
communications pathway accessible to the local device. 
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18. The file transfer device of claim 1, fiirther comprising a parallel polling 
system that causes a local device to poll a directory on at least one of the remote 
devices, the directory being associated with an assigned destination, the local device 
requesting all data within the directory to be transferred to the local device, wherein 

5 multiple remote devices are substantially simultaneously polled and the data is 
transferred substantially simultaneously to the local device from all of the remote 
devices, and wherein the data always transfers to the assigned destination. 

19. The file transfer device of claim 1 , in which the data transfer occurs by 
only logging onto any intermediate computers that provide a signal propagation 

1 0 medium for storageless transfer through the propagation medium. 

20. A file transfer method that enables data transfers between a local device 
and at least one remote device, the method comprising: 

A. establishing a connection with the at least one remote device via 
preestablished listening ports that reside within each device; 
15 B. dynamically assigning a data port within the local device, each data port 

within the local device enabling a data transfer; and 

C. transmitting the address of the data port to the at least one remote device 
via the listening ports; and 

D. transferring data in a data transfer between the connected devices via the 
20 data ports, the data being substantially simultaneously transferred between multiple 

remote devices and the local device via the dynamically assigned data ports. 

21. The method of clahn 20, fiirther comprismg, after establishing the 
connection of A., receiving data transfer characteristics and authenticating the at least 
one remote device by verifying identifying information of the at least one remote 

25 device, the identifying information being transmitted from the at least one remote 
device. 

22. The method of claim 21, fiirther comprising comparuig the remote 
device's identifying information with a list of destination identities stored in the local 
device and prohibiting data transfers from remote devices not within the list of 

30 destination identities. 



wo 99/26121 PCT/US98/24373 

Page -81- 

23. The method of claim 20, in which the local device substantially 
simultaneously sends and receives data to and from multiple devices. 

24. The method of claim 20, further comprising generating and sending a 
return receipt, including point of origin, destination, and successful completion 

5 information, from a device that received the data transfer to a device that transferred 
the data upon successful completion of the data transfer. 

25. The method of claim 24, further comprising communicating with an 
independent certifying processor that verifies return receipts for point of origin, 
destination, and successful completion information, the independent certifying 

10 processor sending a verification certification to the device that transferred the data 
after successful completion of the data transfer, 

wherein the device that received the data transfer generates and sends a return 
receipt to the independent certifying processor upon successful completion of the data 
transfer. 

15 26. The method of claim 20, in which each data port is represented by a 

socket data stracture. 

27. The method of claim 26, in which each device stores the socket data 

structures in a linked list to manage the flow of data transfers, the linked list being 

traversed to enable substantially simultaneous data transfers. 
20 28. The method of claim 20, further comprising maintaining and monitoring 

data transfer credits and detecting each data transfer in order to debit a credit account 

after a successflil data transfer, the data transfer only being permitted when a device 

that initiates the transfer has sufficient credits. 

29. The method of claim 28, further comprising requesting additional credits 
25 from an external credit processor in response to a request from one of the devices for 

additional credits, the external credit processor validating account information of the 
requesting device and dispensing additional credits if the account information is 
validated. 

30. The method of claim 20, further comprising defining an index that can be 
30 requested by remote devices via the connection, the index comprising information 
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indicating at least one file that the remote computer can request a copy of via the data 
transfer, and an associated destination. 

31. The method of claim 30, in which the associated destination is a specific 
destination, and devices corresponding to the specific destination have exclusive 

5 access to the index. 

32. The method of claim 30, in which the associated destination is a general 
destination, and all remote devices have access to the index. 

33. The method of claim 30, further comprising permitting a requesting 
device to select a remote device where a request for an index will be sent, the request 

10 being sent to the selected remote device, the selected remote device retuming the 
index to the requesting device, the requesting device storing the index in a storage 
device. 

34. The method of claim 33, wherein when any file hsted in the index is 
selected by the requesting device, the requesting device requests that a copy of the 

15 selected file be transferred fi-om the selected remote device, the selected remote 
device transferring each file in response to the request. 

35. The method of claim 20, in which each device fiirther comprises: 

a variable number of destination linked directories, each associated with 
another device, each destination Imked directory being a file storage area on the 
20 device; and 

in which the method further comprises detecting storing of at least one data 
file in the destination linked directory and initiatmg a transfer of the detected data file 
to the associated device in response to the detection. 

36. The method of claim 20, further comprising: 

25 periodically determining whether each remote device in a list of at least one 

remote devices is currently actively connected to a communications pathway 
accessible to a local device; 

validating each remote device in the list of at least one remote devices that is 
currently actively connected to the communications pathway accessible to the local 

30 device; and 
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deferring a file transfer to a time when a selected remote device becomes 
actively connected to the communications pathway accessible to the local device, if 
the selected remote device is not currently actively cormected to the communications 
pathway accessible to the local device. 
5 37. The method of claim 20, fiirther comprising polling a directory on at least 

one of the remote devices, the directory being associated with .an assigned 
destination, and requesting all data within the directory to be transferred to the local 
device, wherein multiple remote devices are substantially simultaneously polled and 
data is transferred substantially simultaneously to the local device from all of the 
10 multiple remote devices, and wherein the data transfers to the assigned destination. 

38. The method of claim 20, in which the established connection comprises 
more than one connection, each connection being between two devices via a different 
pair of listening ports, each device selecting listening ports from a predetermined 
range of available ports. 
15 39, A file transfer method that enables data transfers between a local device 

and at least one remote device, the method comprising: 

establishing a connection with the at least one remote device via 
preestablished listening ports which reside within each device; 

receiving an address of a first data port from the at least one remote device via 
20 the listening ports; 

dynamically assigning a second data port, corresponding to the first data port 
within the remote device, within the local device, each data port within the local 
device enabling a data transfer; and 

transferring data between the connected devices via the data ports, the data 
25 being substantially simultaneously transferred to multiple remote devices via the 
dynamically assigned data ports. 

40. The method of claim 39, further comprising, after establishing the 
connection, transmitting data transfer characteristics. 

41. The method of claim 39, in which each local device substantially 
30 simultaneously sends and receives data to and from multiple devices. 
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42. The method of claim 39, further comprising generating and sending a 
return receipt, including point of origin, destination, and successful completion 
information, from a device that received the data transfer to a device that transferred 
the data after successful completion of the data transfer. 

5 43. The method of claim 42, further comprising communicating with an 

independent certifying processor that verifies return receipts for point of origin, 
destination, and successful completion information, the independent certifying 
processor sending verification certification to the device that transferred the data after 
successful completion of the data transfer, 

1 0 wherein the device that received the data transfer generates and sends a return 

receipt to the independent certifying processor upon successful completion of the data 
transfer. 

44. The method of claim 39, m which each data port is represented by a 
socket data structure. 

15 45. The method of claim 44, in which each device stores the socket data 

structures in a linked list to manage the flow of data transfers, the linked list being 
traversed to enable substantially simultaneous data transfers. 

46. The method of claim 39, further comprising maintaining and monitoring 
data transfer credits and detecting each data transfer in order to debit a credit account 

20 after a successfiil data transfer, the data transfer only being permitted when a device 
that initiates the transfer has sufficient credits. 

47. The method of claim 46, further comprising requesting additional credits 
from an extemal credit processor in response to a request from a device for additional 
credits, the extemal credit processor validating account information of the requesting 

25 device and dispensing additional credits if the account information is validated. 

48. The method ofclaim 39, further comprising defming an index that can be 
requested by remote devices via the connection, the index comprising information 
indicatmg at least one file of which the remote device can request a copy via the data 
transfer, and an associated destination, at least one device corresponding to the 

30 associated destination having exclusive access to the index. 



10 
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49. The method of claim 48, fiirther comprising permitting a requesting 
device to select a remote device where a request for an index will be sent, the request 
being sent to the selected remote device, the selected remote device returning the 
index to the requesting device, the requesting device storing the index in a storage 

5 device. 

50. The method of claim 49, wherein when any file listed in the index is 
selected by the requesting device, the requesting device requests that a copy of the 
selected file be transferred from the selected remote device, the selected remote 
device transferring each file in response to the request. 

5 1 . The method of claim 39, in which each device further comprises: 

a variable number of destination linked directories, each associated with 
another device, each destination linked directory being a file storage area on the 
device; and 

in which the method further comprises detecting storing of at least one data 
1 5 file in the destination linked directory and initiating a transfer of the detected data file 
to the associated device in response to the detection. 

52. Hie method of claim 39, further comprising: 

periodically determining whether each remote device in a list of at least one 
remote devices is currently actively connected to a communications pathway 
20 accessible to a local device; 

validating each remote device in the list of at least one remote devices that is 
currently actively connected to the communications pathway accessible to the local 
device; and 

deferring a file transfer to a time when a selected remote device becomes 
25 actively connected to the communications pathway accessible to the local device if 
the selected remote device is not cunrently actively connected to the cornmimications 
pathway accessible to the local device. 

53 . The method of claim 39, fiirther comprising polling a directory on at least 
one of the remote devices, the directory being associated with an assigned 

30 destination, and requesting all data within the directory to be transferred to the local 
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device, wherein multiple remote devices are substantially simultaneously polled and 
the data is transferred substantially simultaneously to the local device from all of the 
remote devices, and wherein the data transfers to the assigned destination. 

54. A file transfer device that transfers data with at least one remote device, 
5 the file transfer device comprismg: 

at least one listening port through which a control connection's established 
to the remote device, the control connection being utilized to determine a remote data 
port for transferring data, each data port enabling a data transfer; and 

at least one dynamically assigned data port for data transfer with the remote 
1 0 data port, the data being substantially simultaneously transferred with multiple remote 
devices via the dynamically assigned data ports. 

55. The file transfer device of claun 54, in which the control connection is 
further utilized to exchange data transfer characteristics. 

56. The file transfer device of claim 54, in which each device substantially 
1 5 simultaneously sends and receives data to and from multiple devices. 

57. The file transfer device of claim 54, further comprising a return receipt 
system that generates and sends a return receipt, including point of origin, destination, 
and successful completion mformation, from the device that received the data transfer 
to the device that transferred the data upon successful completion of the data transfer. 

20 58. The file transfer device of claim 57, further comprising a certifying system 

that communicates v\dth an independent certifying processor that verifies return 
receipts for point of origin, destination, and successful completion information, the 
independent certifying processor sending verification certification to the device that 
transferred the data transfer upon successful completion of the data transfer, 

25 wherein the retum receipt system generates and sends a return receipt from the 

device that received the data transfer to the independent certifying processor upon 
successful completion of the data transfer. 

59. The file transfer device of claim 54, in which each data port is represented 
by a socket data structure. 
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60. The file transfer device of claim 59, in which each device stores the socket 
data structures in a linked list to manage the flow of data transfers, the linked list 
being traversed to enable substantially simultaneous data transfers. 

61. The file transfer device of claim 54, further comprising a credit system 
5 that maintains and monitors data transfer credits and detects each data transfer in 

order to debit a credit account after a successful data transfer, the data transfer only 
being permitted when a device that initiates the transfer has sufficient credits. 

62. The file transfer device of claim 61, in which a number of available 
credits for the device is dynamically displayed on each device. 

10 63 . The file transfer device of claim 6 1 , in which a transmitting device further 

comprises a encrypting system that encrypts selected files prior to transmission, and 
a receiving device further comprises a decrypting system that decrypts each encrypted 
file upon receipt, wherein the number of credits in the transmitting device is modified 
at least one additional credit upon each successful file transfer employing encryption. 

15 64. The file transfer device of claim 61, further comprising a credit request 

system that requests additional credits fi-om an external credit processor in response 
to a request fi-om a device for additional credits, the external credit processor 
validating account information of the requesting device and dispensing additional 
credits if the account information is validated. 

20 65. The file transfer device of claim 54, further comprising an index system 

that defines an index that can be requested by remote devices via the connection, the 
index comprising kifbrmation indicating at least one file that the remote computer can 
request a copy of via the data transfer, and an associated destination, devices 
corresponding to the specific destination having exclusive access to the index. 

25 66. The file transfer device of claim 65, further comprising an index request 

system that permits a requestmg device to select a remote device where a request for 
an index will be sent, the request being sent to the selected remote device, the 
selected remote device returning the index to the requesting device, the requesting 
device storing the index in a storage device. 
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67. The file transfer device of claim 66, wherein when each file listed in the 
index is selected by the requesting device, the requesting device requests that a copy 
of the selected file be transferred from the selected remote device, the selected remote 
device transferring each file in response to the request. 
5 68. The file transfer device of claim 54, in which each device further 

comprises: 

a variable number of destination linked directories, each destination linked 
directory associated with another device, each destination linked directory being a file 
storage area on the device; and 

10 in which the file transfer device further comprises a destination linked 

directory management system that detects storing of at least one data file in the 
destination linked dh^ectory and initiates a transfer of the detected data file to the 
associated device in response to the detection. 

69. The file transfer device of claim 54, further comprising: 

1 5 an active connection monitoring system that periodically determines whether 

each remote device in a list of at least one remote devices is currently actively 
connected to a communications pathway accessible to a local device; 

a validating system that validates each remote device in the list of at least one 
remote devices that is currently actively connected to the communications pathway 

20 accessible to the local device; and 

a monitoring system that defers a file transfer to a time when a selected remote 
device becomes actively connected to the communications pathway accessible to the 
local device if the selected remote device is not currently actively connected to the 
communications pathway accessible to the local device. 

25 70. The file transfer device of claim 54, further comprismg a parallel polling 

system that causes a local device to poll a directory on at least one of the remote 
devices, the directory being associated with an assigned destination, the local device 
requesting all data within the dh-ectory to be transferred to the local device, wherein 
multiple remote devices are substantially simultaneously polled and the data is 



. wo 99/26121 PCT/US98/24373 

Page -89- 

transferred substantially simultaneously to the local device from all of the remote 
devices, and wherein the data always transfers to the assigned destination. 

71. A computer data signal embodied in a propagation medium, the signal 
enabling a variable number of data transfers and comprising: 

5 A. an initial connection source code segment that establishes a connection 

between two devices via predetermined listening ports, at least one predetermined 
listening port residing within each device; 

dynamically assigns a first data port within a first device; and 
transmits the address of the first data port to a remaining device via the 
10 predetermined listening ports; and 

B. a data transfer source code segment for each of the variable number of data 
transfer operations that 

dynamically assigns a second data port within the remaining device 
corresponding to the first data port within the first device, each pair of first and 
1 5 second data ports being established in response to each hstening port connection; and 
transfers data between the connected devices via the data ports, the data being 
substantially simultaneously transferred between a variable number of devices via the 
dynamically assigned data ports. 

72. The signal of claim 71, in which the initial connection source code 
20 segment also exchanges data transfer characteristics and authenticates the remaining 

device by verifying identifying information of the remaining device transmitted from 
the remaining device. . 

73. The signal of claim 72, in which the initial connection source code 
segment further comprises a selective acceptance source code segment that compares 

25 the remaining device's identifying information with a list of destination identities 
stored in the first device and prohibits data transfers from devices not within the list 
of destination identities. 

74; The signal of claim 71, in which each device substantially simultaneously 
sends and receives data to and from multiple devices. 
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75. The signal ofclaim 71, further comprising a return receipt source code 
segment that generates and sends a return receipt, including point of origin, 
destination, and successfiil completion information, from the device that received the 
data transfer to the device that transferred the data upon successful completion of the 

5 data transfer. 

76. The signal of claim 75, further comprising a certifying source code 
segment that communicates with an independent certifymg processor that verifies - 
return receipts for point of origin, destination, and successful completion information, 
the independent certifying processor sending verification certification to the device 

1 0 that originated the data transfer upon successful completion of the data transfer, 

wherein the retum receipt source code segment generates and sends a return 
receipt from the device that received the data transfer to the independent certifying 
processor upon successful completion of the data transfer. 

77. The signal of claim 71, in which each data port is represented by a socket 

15 data structure. 

78. The signal of claim 77, in which each device stores the socket data 
structures m a linked list to manage the flow of data transfers, the linked list being 
traversed to enable substantially simultaneous data transfers. 

79. The signal of claim 7 1 , further comprising a credit source code segment 
20 that maintains and monitors data transfer credits and detects each data transfer in 

order to deduct credit from a credit account after a successful data transfer, the data 
transfer only being permitted when the device initiating the transfer has sufficient 
credits. 

80. The signal of claim 79, in which the remaining device comprises a 
25 transmitting device comprising an encrypting source code segment that encrypts 

selected data prior to transmission; and 

the first device comprises a receiving device comprising a decrypting source 
code segment that decrypts each encrypted file upon receipt; 
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wherein data transfer credits comprise a definite number of credits, and 
wherein the number of credits in the transmitting device is modified at least one 
additional credit upon each successful data transfer employing encryption. 

8 1 . The signal of claim 79, further comprising a credit request source code 
5 segment that requests additional credits from an external credit processor in response 

to a request for additional credits from one of the devices, the extemal credit 
processor validating account information of the requesting device and dispensing 
additional credits if the account information is validated. 

82. The signal of claim 71, further comprising an index source code segment 
1 0 that defines an index for request by remote devices via a connection, the index being 

associated with at least one destination and listing information representative of at 
least one file that the remote devices can request, devices corresponding to the 
associated destination having exclusive access to the index. 

83. The signal of claim 82, further comprising an index request source code 
1 5 segment that permits a requesting device to select a particular remote device to which 

a request for an index will be sent, the request being sent to the selected remote 
device, the remote device returning the index to the requesting device, the requesting 
device storing the index in a storage device. 

84. The signal of claim 83, further comprising an index transfer source code 
20 segment that, in response to each file listed in the index being selected by the 

requesting device, permits the requesting device to request a copy of the selected file 
to be transferred from the remote device, the remote device transferring each file in 
response to the request. 

85. The signal of claim 71, in which the initial source code segment 
25 establishes more than one connection, each connection being between two devices 

via a different pair of listening ports, each device selecting listening ports from a 
predetermined range of available ports. 

86. The signal of claim 71, in which each device further comprises: 
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a variable number of destination linked directories, each destination linked 
directory associated with another device, each destination linked directory being a file 
storage area on the device; and 

in which the signal further comprises a destination linked directory 
5 management source code segment that detects storing of at least one data file in the 
destination linked directory and initiates a transfer of the detected data file to the 
associated device in response to the detection. 

87. The signal ofclaim 71, further comprising: 

an active cormection monitoring source code segment that periodically 
10 determines whether each remote device in a list of at least one remote devices is 
currently actively connected to a communications pathway accessible to a local 
device; 

a validating source code segment that validates each remote device in the list 
of at least one remote devices that is currently actively connected to the 
15 communications pathway accessible to the local device; and 

a monitoring source code segment that defers a file transfer to a time when a 
selected remote device becomes actively connected to the communications pathway 
accessible to the local device if the selected remote device is not currently actively 
connected to the communications pathway accessible to the local device. 
20 88 . The signal of claim 7 1 , further comprising a parallel polling source code 

segment that causes a local device to poll a directory on at least one of the remote 
devices, the directory being associated with an assigned destination, the local device 
requesting all data within the directory to be transferred to the local device, wherein 
multiple remote devices are substantially simultaneously polled, and the data is 
25 transferred substantially simultaneously to the local device from all of the remote 
devices, and wherein the data transfers to the assigned destination. 

89. A data file delivery system for delivering data files between a variable 
number of devices, comprising: 

a variable number of peer systems, each peer system having: 
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a connection negotiating system for opening at least one listening port for 
exchanging control data; 

a data connection system for opening a variable number of data ports, each 
associated with a destination, for exchanging data files; 
5 a file selection system for selecting a variable number of data files residing on 

at least one peer system designated as a file source; and 

a destination selection system for selecting a variable number of destinations 
for receiving the selected data files, 

at least the file source having a transmitting system for storageless sending of 
10 the selected data files over a variable number of data communications pathways 
corresponding to the data ports, 

the destinations each having a receiving system for storageless receiving of the 
files sent via storageless sending, and 

at least one of the file source and the destination having an initiating system 
15 for initiating operation of the transmitting system, via at least one communications 
negotiating pathway corresponding to the at least one listening port, from either the 
file source or the destination. 

90. The data file delivery system of claim 89 wherein each file source is also 
a destination having a receiving system for storageless receiving of files sent via 

20 storageless sending by at least one other peer system acting as a subsequent file 
source at the same time that the transmitting system operates. 

91. The data file delivery system of claim 89, in which each peer further 
comprises: 

a variable number of destination linked directories, each associated with 
25 another device, each destination linked directory being a file storage area on the 
device; and 

a destination linked directory management system for detecting storing of at 
least one data file in the corresponding file storage area and for controlling the 
initiating system to initiate operation of a transceiver system in response to the 
30 detection. 
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92. The data file delivery system of claim 89, each peer system fiirther 
comprising: 

a return receipt system, for generating and sending a return receipt including 
point of origin, destination, and successfiil completion information from each 
5 destination peer system receiving the selected files to the file source over the 
storageless communications pathway corresponding to the data ports upon successful 
completion of the storageless receiving of the selected files. 

93. The data file delivery system of claim 92, further comprising: 

a third party transaction certificate processor for examining and verifying 
1 0 return receipts for point of origin, destination, and successful completion information, 
and for sending verification certificate data files over a first additional storageless 
communications pathway corresponding to a first additional data port to the file 
source peer system upon successful completion of the storageless receiving of the 
selected files; 

15 wherein the return receipt system generates and sends a return receipt from 

each destmation receiving the selected files to the third party transaction certificate 
processor over a second storageless communications pathway corresponding to a 
second additional data port upon successful completion of the storageless receiving 
of the selected files. 

20 94. The data file delivery system of claim 89, each peer system further 

comprising: 

a file credit monitoring system for maintaining and monitoring file delivery 
credits, the file credit monitoring system detecting each storageless sending of 
selected file and debiting a credit account variable on an associated peer system in 
25 accordance with a function based on the storageless sending. 

95. The data file delivery system of claim 89, further comprising: 
a credit processor for receiving credit requests, and for incrementing a credit 
account variable on an associated one of the peer systems upon receipt of a credit 
request and successful comparison of the credit request against a credit authorization 
30 fimction, 
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wherein the file credit monitoring system generates and sends a credit request 
from one of the peer systems to the credit processor. 

96. The data file delivery system of claim 89, each peer system further 
comprising: 

5 an index generating system for generating an index of files on a peer system; 

an index requesting system for requesting and retrieving an index of files from 
any one of the variable number of peer systems; 

a subset selecting system for selecting a subset of a variable number of files 
from the retrieved index of files from any of the variable number of peer systems; and 
10 a file subset requesting system for initiating operation of the transceiver 

system to transfer the subset from any one of the variable number of peer systems to 
the peer system. 

97. The data file delivery system of claim 89, each peer system fiirther 
comprising: 

15 a transceiver management system for managing substantially parallel and 

simultaneous operation of a variable number of transceiver systems for substantially 
parallel and simultaneous storageless sending and storageless receiving of the 
selected files over a plurality of communications pathways correspondmg to a 
plurality of data ports. 

20 98 . The data file delivery system of claim 89, m which the data transfer via 

the communications pathway occurs without logging onto any intermediate 
computers, without logging onto the destination, and w^ithout intermediate storage of 
transmitted files on an intervening computer. 

99. The data file delivery system of claim 89, wherein the connection with the 
25 destination via the data port is to a destination address received with the control data. 

100. The data file delivery system of claim 89, in which when a file is saved 
to a predetermined directory associated with a destination, the file is transferred to the 
destination. 

101. A file transfer system for transferring files between at least one local 
30 computer and at least one remote computer selected from a list of at least one remote 
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computers, across at least one communications pathway, the file transfer system 
comprising: 

a file selector that selects at least one file stored on the local computer for 
transferring to the at least one remote computer; 
5 a destination selector that selects, from the list of at least one remote computer, 

at least one remote computer designated as a destination computer to which the file 
will be transferred; 

a transmitter that transfers the selected file to the destination computer via the 
at least one communications pathway without storing the selected file on any 
1 0 intermediate computers; 

a receiver that receives the transferred file; 

an initial connection system that establishes a connection between the local 
computer and the destination computer via predetermined listening ports, at least one 
predetermined listening, port residing within each computer, data transfer 
15 characteristics being exchanged during the initial connection, identities of the local 
and destination computers being authenticated by verifying each computer's 
identifying information; 

a first allocator that dynamically assigns a first data port represented by a 
socket data structure within the destination computer; 
20 a first transmitter that transmits the address of the first data port to the local 

computer via the predetermined listening ports; 

a second allocator that dynamically assigns a second data port represented by 
a socket data structure within the local computer corresponding to the first data port 
within the destination computer, each pair of first and second data ports being 
25 dynamically assigned in response to each listening port connection; 

a second transmitter that transfers data between the connected computers via 
the data ports, the data being substantially simultaneously transferred between a 
variable number of computers via the dynamically assigned data ports; 

wherein each computer is capable of substantially simultaneously sending and 
30 receiving data, 
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wherein each computer dynamically manages socket data structures to enable 
substantially simultaneous data transfers, 

a generator that generates and sends a return receipt, including point of origin, 
destination, and successful completion information, from the computer that received 
5 the file transfer to the computer that transferred the file, and an independent 
certifying processor upon successful completion of the file transfer; 

a third transmitter that communicates with the independent certifying 
processor that verifies retum receipts for point of origin, destination, and successful 
completion inforaiation, the independent certifying processor sending verification 
10 certification to the computer that originated the file transfer upon successful 
completion of the file transfer; 

a credit system that maintains and monitors file transfer credits and detects 
each file transfer in order to debit a credit account after a successful file transfer, the 
file transfer only being permitted when the computer initiating the transfer has 
15 sufficient credits; and 

a credit request system that requests additional credits from an external credit 
processor in response to a request from a computer for additional credits, the external 
credit processor validating account information of the requesting computer and 
dispensing additional credits if the account information is validated. 
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(54)Titte: FILE TRANSFER SYSTEM 
(57) Abstract 

A file transfer device, system, and method (Fig, 1) are 
provided. The device, system, and method enable a variable number 
of data transfers (S56) and include an initial connection system 
(864) and data transfer system. The initial connection system (S64) 
establishes a connection between at least two devices via 
predetermined listening ports (1402), with at least one 
predetermined listening port (1402) residing within each of the at 
least two devices. The initial connection system (S64) also 
dynamically assigns (S44) a first port within a first device, and 
transmits the address (1414) of the first data port to a remaining 
device via predetermined listening ports (1402). 
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